Statement of Work Checklist: Review Scope Before Anyone Signs

A statement of work checklist is useful only if it catches the document's weak spots before signature. The checklist below is written for a consulting engagement: a strategy team will review branch-level service performance for a regional bank and produce a recommendations report. The work seems simple until the client asks whether the consultant will also design training, join branch meetings and prepare board materials.

Use the checklist as a review gate, not a writing template. The goal is to make sure the SOW can stand alone when memories fade. Public-sector sources are helpful references for this discipline. FAR says SOWs for certain federal schedule services include the work description, location, performance period, deliverable schedule, performance standards and special requirements FAR 8.405-2. Oregon's SOW guide recommends tangible, measurable deliverables and a review meeting before execution ODOT SOW Writing Guide. Those are not private-sector legal requirements, but they are practical tests.

Scope boundaries

First ask what the SOW authorizes. If the answer is "the consulting project," it is too broad. A workable boundary states the project, governing agreement, locations, period and limits.

Checklist questions:

• Does the SOW identify the client, consultant, governing agreement and effective date?
• Are in-scope activities stated with quantities, formats or locations where possible?
• Are out-of-scope activities named, especially likely misunderstandings?
• Does the SOW say which document prevails if it conflicts with a master agreement?

Draft language:

This SOW authorizes [Consultant] to review service performance reporting at [number] branches and produce the deliverables listed in Section 3. It does not authorize branch training, system configuration, board presentation materials or review of locations not listed in Appendix A.

Annotation: the sentence names the work and the edge of the work. It also keeps the exclusions close to the authorization so they are not missed.

Work packages

A work package should be small enough to assign and inspect. Avoid packages named "analysis support" or "implementation assistance." The work package should identify the activity, owner, output and dependency.

Checklist questions:

• Does each package have one accountable owner?
• Is each output inspectable?
• Are client inputs named with due dates?
• Does the SOW say what happens if an input is late or incomplete?

If a later phase is uncertain, do not pretend it is known. Write the first phase in detail and require a written amendment or change request for later phases.

Acceptance criteria

Acceptance criteria are not compliments. "Accepted when the sponsor is happy" is not a criterion. A criterion should let the reviewer say yes, no or yes with listed corrections. FAR performance-based guidance says standards should be measurable and structured to permit assessment FAR 37.602.

Draft language:

The recommendations report is accepted when it includes the agreed sections in Appendix B, cites the evidence used for each recommendation, and the sponsor confirms in writing that the recommendations and evidence have been reviewed. If rejected, the sponsor lists each shortfall against these criteria within [number] working days.

Checklist questions:

• Is there one reviewer for each deliverable?
• Is the review window stated?
• Is rejection tied to listed criteria, not taste?
• Does the SOW reject silent acceptance unless the parties intentionally choose it?

For consulting work, acceptance often turns on evidence. Require the report to identify the interview note, data extract or decision record behind recommendations. That reduces arguments about whether the consultant merely guessed.

Change control

Change control belongs in the SOW before anyone needs it. It should cover who may request a change, what information is required, who assesses impact, who approves, and where the approved version is kept.

Draft language:

Either party may request a change in writing. The request must describe the proposed change, reason and desired date. [Consultant] will state the effect on scope, fees, schedule and acceptance criteria within [number] working days. No change is effective until approved in writing by [client authorizer] and [consultant authorizer].

Checklist questions:

• Does the SOW prevent informal scope expansion?
• Are fee and schedule impacts assessed before approval?
• Is the approved baseline updated?
• Are rejected and deferred requests kept with reasons?

Signature-readiness checklist

Run one final pass after legal or commercial review so changes have not created contradictions. Read the SOW as if you joined the project tomorrow. Can you find the current scope, the next milestone, the client inputs, the deliverable tests and the change route without asking anyone?

A good checklist is blunt. It should stop the document when there is no named reviewer, no consequence for late inputs, no exclusion for likely add-ons or no approval authority. The friction is the point: it is cheaper to fix a SOW before signature than to negotiate what someone meant after the work is underway.

Worked checklist item: board materials are not the same deliverable

In the branch-service scenario, the client may ask for "a few slides for the board" after seeing the recommendations report. That request feels adjacent, but it changes the audience, tone, review path and risk of the work. A report for the sponsor can include operational detail, unresolved evidence gaps and branch-level nuance. Board materials usually require executive framing, financial implications and a higher degree of message control.

Treat this as a checklist failure if the SOW says only "recommendations support." The phrase does not tell anyone whether the consultant is preparing an internal management report, board-ready slides, talking points or live presentation support.

Better SOW wording:

The deliverable is a recommendations report for the client sponsor and service-performance working group. Board deck preparation, executive talking points and attendance at board or committee meetings are excluded unless added by written change request. If added, the change will state the audience, page limit, financial-input owner, review cycle and presentation role.

Why the choice follows from the evidence: the original project evidence is branch reporting, manager interviews and service measures. That evidence supports an operational recommendation report. It may inform board materials, but it does not automatically supply board-level financial analysis or executive positioning. By separating the deliverables, the SOW keeps advisory analysis from expanding into a communications workstream without a new scope decision.

The checklist should also catch who supplies numbers for any executive version. If finance owns cost estimates or benefits calculations, the SOW should not let the consultant become the source of those figures by accident. A useful change request might say: "Finance provides branch-cost assumptions and validates any financial slides; the consultant may format those inputs but does not independently certify them." That distinction matters because the consultant's evidence base is service-performance work, not the bank's full financial model.

If the sponsor truly needs both products, split them. Keep the recommendations report accepted against evidence and analysis criteria. Give the board deck its own page limit, audience, draft date and comment owner. That way a late request to soften language for executives does not reopen acceptance of the underlying consulting report.

Start from an editable Word draft

Use the consulting statement of work template to document the branch review as authorized work, with the report audience, exclusions, review window and change route visible before anyone signs.