Veeva · Delivery July 2026 · 9 min read

How to Read an SOW Like an Implementation Architect

Part 1 of 2: A practical guide for organisations buying Veeva implementation services.

A Statement of Work can be commercially precise and still buy the wrong architecture. Precision and correctness aren't the same test, and most buyers only check for the first one.

I've read SOWs from both sides of the table, as the person deciding whether to sign one and as the person brought in later to explain why an implementation described as successful didn't hold up in operation. The same gap appears every time, and it's worth naming plainly before getting into the mechanics: most of the programmes I have heard of didn't land on the budget or the timeline that was in the original SOW. It's rarely the big, visible thing that moves it, a scope fight, a vendor going dark. More often it's the sections everyone reads once and treats as boilerplate, the assumptions, the risk-allocation wording, who's actually staffed, how the whole thing is supposed to end. Nobody interrogates those at signature, so nobody's actually decided who owns the slippage before it happens, and by the time it does, there's no clean answer left, just a negotiation with the meter already running.

“Migration included.” “Partner will support UAT.” “Standard configuration will be used.” Each phrase sounds specific, because it names a real activity. None of them says what must be delivered or how completion gets proved, and neither one tells you who's on the hook if the assumption sitting underneath the sentence turns out to be wrong.

That's why I read an SOW as architecture, not as a commercial document that happens to mention technical work.

Start with the agreement stack

An SOW is rarely the whole agreement. Veeva describes its own customer relationship as governed through a Master Subscription Agreement, with Order Forms and Statements of Work sitting under it. Read the SOW alone and you can miss the clause elsewhere in the stack that governs warranty, ownership of custom work product, or what survives after the engagement ends.

Ask for the full stack before you review the SOW. Then ask which document wins if two terms conflict, what belongs to you after payment versus what's only licensed, and where liability and remedy limits actually live. None of that replaces legal review. It tells you whether the delivery model in the SOW can actually produce the outcome you're expecting.

Four tags, and nothing else matters

Once I have the stack, every meaningful sentence gets one of four tags. A Deliverable is a work product I can inspect and accept. An Assumption is a dependency the price is quietly resting on, and Risk Allocation is the harder one, the wording that decides who actually absorbs the cost when that dependency doesn't hold. A Test is the only evidence that a deliverable is actually done, and it's usually the tag most SOWs skip. Everything else is narrative. Narrative explains the project; it doesn't govern it.

The value isn't really in the tagging itself, it's in noticing what refuses to be tagged cleanly. A major activity with no deliverable attached means you don't know what you'll actually receive, and an assumption sitting with no stated consequence usually means nobody's decided who pays if it fails either.

“Migration complete” can mean two different things

“Migration included” means almost nothing without a boundary around it, source systems, record types, volumes, mapping ownership, mock cycles, reconciliation method. The reconciliation method is where it actually matters, more than most buyers expect going in.

Mechanical reconciliation checks record counts and checksums, which really only proves the files arrived. Semantic reconciliation is the harder, less comfortable question, whether the migrated record still means what it meant before, whether Quality could still explain why it was closed or superseded without reconstructing the history by hand. A closed deviation hasn't migrated successfully just because the count matches. Its history has to stay intelligible, or what you've actually bought is data movement, not a usable record, and you may not find that out until someone needs the record for something real.

Deliverables versus activities

“Configure review workflows” describes work. It doesn't define a deliverable. “Configure the workflows listed in Appendix A and deliver the approved configuration workbook, security mapping, and test evidence for each one” gives me something to actually examine.

The same gap runs through the whole document. “Conduct design workshops” doesn't say who's actually recording the decisions made in the room, as opposed to just running the meeting. “Configure reports” doesn't name which reports, or which data sources feed them. And “support cutover” is often the vaguest of the lot, since it never says who owns the go-live decision itself when something looks borderline on the day.

A verb tells you what the partner intends to do. It rarely tells you what you'll actually be left holding.

Related reading: The SOW can't repair an unresolved decision model — that's a different problem: Your Veeva Programme Has a Project Plan. Does It Have an Architecture?

Assumptions are risk, priced at zero

I spend more time here than most buyers do. “Customer test data will be representative of production” sounds procedural. If your real data is messier than the curated set you tested against, the partner's obligation was already satisfied, and closing that gap becomes a change request.

Rewrite the vague ones. Name the actual input, name who owns providing it, put a real date or service level against it, and be honest about what happens if it's missed. “Timely feedback” becomes a number of working days. “Appropriate SMEs” becomes named functions with real availability, though in practice you often can't pin this down as precisely as you'd like until the programme's already under way, which is itself worth flagging in the SOW rather than pretending the ambiguity doesn't exist.

The words that move risk

Watch for a specific vocabulary: reasonable effort, subject to data quality, standard functionality, customer-caused delay, third-party dependency, out of scope unless expressly stated. None of these phrases is automatically unreasonable on its own. Each one is doing quiet work, deciding who owns the cost once delivery turns out to be harder than the estimate assumed.

The test I actually use is simple. Does whoever's carrying the risk also control the condition that creates it? If you're on the hook for a third-party delay you have no influence over, that allocation deserves a real challenge, not a shrug. And if the partner's plan leans on “customer data quality,” the SOW should say what profiling, rejection, and remediation actually looks like, rather than leaving that phrase to mean whatever's convenient in month four.

The validation split most buyers never ask about

Veeva performs and documents IQ and OQ for the core platform with each release. That's real, and it reduces your validation burden. It does not cover your configuration. You remain responsible for validating the specific workflows and business logic your partner built, through your own UAT and PQ.

“Support UAT” could mean a full test team, or it could mean showing up to a call twice a week. Separate who writes the scripts, who executes them, who triages defects, who corrects the configuration, and who signs off. Then check how many correction and retest cycles are actually priced in, because a fixed fee built around one clean pass gets unstable fast once real data shows up.

I also check who can actually approve a process, architecture, or validation decision when it comes up mid-programme. “Customer approval” is too vague to mean anything once Quality owns the process, Digital owns the platform, and the partner's running the design workshops where the real calls get made. I've written elsewhere about that broader ownership problem and won't repeat it here. The narrower point for an SOW specifically is this: an approval deadline is meaningless if nobody's named who's actually authorised to approve.

The release calendar belongs in the SOW

Veeva ships a major Vault release roughly every four months, about three a year. If your design, UAT, or cutover collides with one, somebody has to assess regression impact and absorb the delay, and silence on this in the SOW doesn't mean the cost is covered, it usually just means nobody's thought about it yet.

Contract for a team, not a logo

The team in the pitch isn't contractually the team that shows up after signature. Veeva itself recommends customers verify which partner employees are actually certified at RFP, pitch, and kick-off. Go further than that: name the roles that materially affect delivery, solution architect, migration lead, validation lead, confirm experience level, and require a controlled substitution process if someone leaves. That said, I have never heard of a substitution clause actually stopping a good consultant from being pulled onto a bigger account mid-programme, it mostly just gives you a paper trail and a weaker negotiating position after the fact rather than before, so the real protection is knowing who's assigned before you sign, not the clause that promises to notice if they change.

Hypercare should end on evidence, not a date

Thirty days, sixty days, an elapsed month proves the earth rotated, not that your team can operate the platform on its own.

Before the partner demobilises, give your own team a real, complex configuration change and watch them take it from impact assessment through testing and deployment without leaning on the partner's memory. If they can't do it unassisted, hypercare probably isn't actually over yet, even if the invoice says it is.

Tests are the only thing that closes the obligation

“Milestone is complete when the vendor confirms it's complete” hands the supplier both the evidence and the decision. A real acceptance clause says what you review, how long you have, how a defect gets classified, and what triggers payment. No defect-severity model means no acceptance mechanism, just an argument scheduled for later.

And test for the right claim. “Performs to the functional specification” is not the same as “validated,” and it's not the same as “Quality recognises this as its process.” A demo is not evidence.

Watch it work on one real sentence

“The partner will support configuration, migration, validation and UAT” is a sentence you'll see in almost every Veeva SOW. Tag it and it comes apart. Configuration: which components, what proves deployment. Migration: which sources, how many mock cycles, who owns reconciliation. Validation: which documents the partner authors versus what you approve. UAT: who writes, who executes, who signs off, how many retest cycles are priced in.

That one sentence might represent hundreds of days of effort, and as written it gives you no basis for estimating, governing, or accepting any of it. That's how ordinary wording turns into an expensive disagreement eighteen months later.

Before you sign

Answer these without guessing, or treat the gap as an unresolved decision that will still get made, just later, under schedule pressure, in whoever wrote the SOW's favour.

What exactly will I receive, and what proves it's complete?
Who owns migration meaning, not just migration counts?
Who authors, executes, and approves validation and UAT, and how many retest cycles are priced in?
Which assumptions could move cost or timeline, and what happens if one fails?
Who can actually approve a process, architecture, or risk decision when one comes up?
Which roles are actually committed, and how are substitutions controlled?
What measurable condition, not what date, ends hypercare?

Every section above is something I have heard of being written off as boilerplate right up until it became the actual reason a programme finished months late with nobody quite able to say why. It's rarely one clause. It's six or seven ordinary-sounding ones, each quietly absorbing a bit of risk nobody priced, and they tend to come due together, not one at a time.

A clear SOW doesn't answer the earlier question either: what kind of implementation capability are you actually buying, and from whom. A company can pick the right Veeva product, negotiate a genuinely tight SOW, and still choose a partner model that rewards speed over architecture, or quietly leaves the operating team dependent long after go-live. That is the subject of Part 2, coming next week:

Buying Veeva Is Easy. Buying the Wrong Implementation Is Expensive.