Do Not Sign the Implementation SOW Until the Finish Line Is Measurable

You are not only buying a platform. You are buying the work required to make it usable.

That work usually lives in the implementation statement of work, or SOW. It may cover discovery, configuration, integrations, data migration, testing, training, cutover, and support after launch.

Buyers still spend most of their evaluation time on platform features and subscription price. Then the SOW arrives late, full of phrases such as “standard configuration,” “customer to provide resources,” and “integration support as needed.”

That is where a good technology decision can turn into an expensive project argument.

Do not sign the implementation SOW until the finish line is measurable. The document should tell you what will exist, who will do the work, how you will test it, what it will cost, and what happens when an assumption fails.

The SOW is part of the product

A strong product with a weak implementation scope is still a weak purchase.

Your users do not experience the software demo. They experience the configured system, migrated data, working integrations, trained processes, and support model that remain after the project team leaves.

Pull the order form, master agreement, implementation SOW, security addendum, support terms, and every document incorporated by reference. Read them together. The SOW may describe the project while the master agreement controls acceptance, payment, liability, ownership, and changes.

This is a commercial and operating review, not a substitute for legal advice. Legal should review the agreement. IT and the business still need to decide whether the described work can produce the required outcome.

Start with one blunt question:

If the provider completes every written obligation exactly as stated, will the business have a usable result?

If the answer is unclear, the scope is not ready.

Define the accepted result before the task list

A long task list can look thorough while avoiding the result.

“Configure platform” is a task. “Approved users can authenticate through the company identity provider with the required access roles” is a testable result.

“Assist with data migration” is a task. A usable result identifies the records to move, the target fields, the allowable exceptions, the reconciliation method, and the person authorized to accept the migrated data.

The federal acquisition rules do not govern a normal private-sector software purchase, but they offer a useful design test. FAR 37.602 tells agencies to describe service work in terms of required results and enable assessment against measurable performance standards. FAR 37.601 pairs measurable standards with a method for assessing performance.

Commercial buyers can use the same logic without copying federal contract language.

For each major deliverable, write down:

Deliverable	Required result	Acceptance evidence	Approver	Due point
Identity integration	Approved users sign in and receive assigned roles	Test results for each role and exception log	Identity owner	Before user testing
Data migration	Required records load into mapped fields within agreed tolerances	Reconciliation report and business sample review	Data owner	Before cutover approval
Workflow configuration	Named business scenarios complete with correct routing and approvals	Signed test script results	Process owner	Before production launch
Admin handoff	Internal team can perform agreed routine administration	Completed runbook and observed admin exercise	Service owner	Before project close

Use your actual systems, volumes, tolerances, and approvers. The table is a structure, not a contract template.

Put integrations and dependencies in writing

Integrations are where vague scope gets expensive.

A proposal may say that the platform “supports” an integration. That does not mean the implementation fee includes discovery, credentials, field mapping, custom development, testing, error handling, or production support.

Build a dependency register before signature. Include every identity service, source system, destination, carrier, API, data owner, security review, network change, third party, and internal approval needed for launch.

For each dependency, ask:

Is the connector native, configurable, custom, or supplied by another party?
Which team owns credentials, access, mapping, testing, and ongoing support?
What usage limits, license requirements, or separate charges apply?
What happens when the upstream system changes?
Is failure handling included, or does the workflow simply stop?
Which dependency can move the schedule, and who carries that cost?

Do not accept “customer responsible for integrations” as a complete answer. It may be a valid commercial boundary, but you still need to know which customer team, what work, by what date, and with what provider assistance.

If discovery is needed to answer those questions, buy discovery as a defined phase. Our guide to buying an AI assessment before implementation shows how to make paid discovery produce a decision packet instead of a generic slide deck.

Separate provider work from buyer work

Many project delays begin with buyer obligations that nobody staffed.

The SOW should name what the provider needs from you: system access, subject matter experts, test data, security approval, decisions, training attendance, change windows, and signoff. It should also state how much time you have to respond and what happens when you miss that window.

Do not let “customer will provide timely resources” hide the internal cost.

Create a responsibility table with one accountable owner for each item. Use provider, buyer, or third party. Avoid shared ownership unless the document also defines which party drives the task and which party approves it.

Then price the buyer work. Count internal project management, data cleanup, testing, security review, business-user time, training, legacy-system support, and work performed by other vendors. The implementation fee is not the implementation cost.

A fixed vendor fee can sit next to a large, open-ended internal workload. Finance needs both numbers before approving the business case.

Make acceptance a process, not a calendar date

Acceptance should prove that the agreed result works. It should not happen automatically because a date passed or the provider sent an invoice.

The SOW needs to answer:

Who submits a deliverable for acceptance?
What evidence arrives with it?
How many business days does the buyer have to review?
Who can accept or reject it?
What counts as a material defect?
How will the provider correct rejected work?
When does the review period restart?
What happens to payment while a material item remains open?

FAR 46.401 offers another useful procurement principle: quality assurance should determine whether services conform to contract requirements, and the surveillance plan should identify the work being checked and the method used. Again, your commercial agreement is different. The practical lesson is that “buyer will test” is incomplete unless the test and evidence are defined.

Be careful with deemed acceptance. A short review window may be reasonable for a simple deliverable. It is risky when the buyer cannot realistically run production-volume tests, obtain business approval, or validate migrated data in that period.

Control changes before the project needs one

Every implementation changes. The problem is not change. The problem is discovering that nobody agreed on how change affects price, schedule, dependencies, or acceptance.

The SOW should define a change request process before work starts. A useful change record states:

The requested change and why it is needed
Whether it corrects a missed requirement, changes an assumption, or adds new scope
The effect on fees, timeline, staffing, security, and other deliverables
The person authorized to approve the change for each party
Whether work pauses while the decision is open
The new acceptance criteria, if any

Do not allow a project meeting note to become an accidental commercial commitment. Operational teams can discuss options. Only named commercial owners should approve a change to scope, price, or term.

Also look for one-sided language that lets the provider treat almost any complication as out of scope. If the vendor estimated the work based on assumptions, list those assumptions and define what evidence proves one was wrong.

Price the whole implementation

Ask for a price schedule that separates:

Discovery and design
Configuration
Each integration
Data preparation and migration
Testing support
Training
Cutover and hypercare
Travel or other expenses
Usage or consumption charges during implementation
Optional work and change-order rates
Ongoing support after project close

Tie payment milestones to accepted deliverables where the parties agree, not only to elapsed dates or hours consumed. A time-and-materials structure may be appropriate when the work cannot be fully known. If so, require rate cards, estimates by workstream, approval thresholds, spend reporting, and a clear decision when the estimate changes.

Fixed fee does not remove scope risk. Time and materials does not remove accountability. The commercial model has to match how well the work is understood.

Run the sign-or-correct test

Before signature, score the SOW against these questions:

Does every major workstream end in a measurable result?
Are integrations and third-party dependencies named?
Are provider, buyer, and third-party responsibilities assigned?
Are assumptions specific enough to test?
Are acceptance evidence, approvers, and review windows defined?
Does the change process show the effect on cost and schedule before approval?
Are data migration, training, cutover, hypercare, and admin handoff included or explicitly excluded?
Does the project price include the likely internal and external work?
Can you delay closeout when a material deliverable remains incomplete?
Do the SOW, order form, and master agreement tell the same story?

If the answer is no on a material item, correct it before signing. Do not rely on the kickoff meeting to fix a commercial gap. The kickoff team may not have authority to change the agreement, and by then your leverage is already smaller.

A clean SOW will not guarantee an easy implementation. It will make the hard parts visible while you can still assign owners, adjust the budget, narrow the scope, or choose another provider.

The platform matters. The finish line matters more.

If you are reviewing a technology purchase with implementation work attached, request a Contract and Spend Risk Review. Bring the order form, master agreement, SOW, pricing, assumptions, and implementation plan. Catch Advisors will help you find unclear obligations, unpriced work, and acceptance gaps before they become change orders.