Veeva · Delivery August 2026 · 8 min read

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

Part 2 of 2: The partner and delivery-structure decisions a tight SOW can't make for you.

A recognised partner and a tight SOW still won't tell you who's allowed to say no.

What follows is a composite drawn from more than one programme, details combined and altered to protect confidentiality; the governance failure itself is real and unchanged. Partway through a global QMS rollout, a partner's architect proposed a shared taxonomy across three business units: lighter to configure, and inside the current sprint. The client's own quality lead flagged that one unit's deviation process didn't map onto it cleanly, but there was no one with the standing to make that objection stick against a milestone the partner was commercially committed to meeting. The shared taxonomy shipped. Eighteen months later that unit was running a parallel spreadsheet to bridge the gap, and the eventual fix meant re-architecting the taxonomy live, mid-validation, at a cost nobody had planned for because nobody had named it as a decision in the first place.

That's the question a tight SOW never actually answers: who has independent authority to reject a design that satisfies the contract while weakening the architecture underneath it? Not a steering committee, a specific person or role, with standing to say no to the partner whose own delivery plan the design came from.

I've watched this play out enough times to trust the pattern: organisations spend months proving the platform decision, an RFP, a bake-off, a steering committee presentation, then days on the decision that actually carries the variance, and I've seen several programmes struggle for exactly that reason.

The credentials buyers do check don't help as much as they look like they should. Veeva's own Services Partner tiers publish numeric minimums for Base, three reference projects, three certified consultants, three verified projects in a product area, and Preferred, six of each. Premier, the tier buyers are likeliest to treat as the strongest signal, has no published numerical minimum. Veeva may well apply an internal bar; buyers simply can't see it, which means the credential doing the most reassuring work is the one they can verify least.

Four jobs, one contract

I count at least four different jobs in a Veeva programme, usually bought as one line in a single SOW:

Diagram: Four jobs, one delivery model. Product delivery, process translation and assurance sit inside the delivery SOW; client-side architecture authority sits across the contract boundary and must be appointed and empowered by the client, not delivered by the partner.

Product delivery — configuration, integrations, migration execution, reports, deployment.
Process translation — turning how Quality, Regulatory or Clinical actually make a decision into objects, lifecycles, workflows and roles, and telling a genuine regulatory requirement from a local habit dressed up as one.
Assurance — proving the configured system supports its intended use: validation strategy, testing, traceability.
Architecture authority — protecting the target state across the whole programme: where standardisation matters, which exceptions are acceptable, what the operating organisation has to be able to own once the partner leaves.

A good partner can do the first three well, and can even propose the fourth, documenting the trade-offs and flagging the consequences of each option. Holding that fourth job on the client's behalf is different, structurally. It means being able to reach a different conclusion from the partner's own delivery plan, and that's a hard thing to ask of the same organisation whose commitments on scope, margin and schedule the conclusion would work against.

Related reading: I've written before about why that fourth job needs to be assigned before configuration starts: Your Veeva Programme Has a Project Plan. Does It Have an Architecture? The question here is narrower, and comes earlier: which partner and which delivery structure actually let that assignment hold once money and a deadline are involved.

What a real disagreement actually looks like

Most partner evaluations run on price, credentials on a slide, a client logo list and a proposed timeline. All four are visible and easy to compare, and, per the Premier tier above, not always as verifiable as they look.

Ask a prospective partner for a real version of the taxonomy moment above, an actual instance where the sprint-friendly option and the long-term-friendly option split, and listen for whether it went to a real decision-maker or got quietly resolved in favour of whichever option hit the milestone. Fixed-price and milestone-based delivery can push toward the sprint-friendly answer on its own, because the commercial measure at that point is demonstrable progress, not long-term architectural fitness.

The other signal, the one that connects back to reading an SOW well, is whether the proposal itself makes its assumptions and exclusions visible, or buries them in language built to survive a negotiation rather than inform one. A partner willing to be explicit about what it doesn't yet know, before anything's signed, is telling you something real about how it will behave once the ambiguity shows up mid-programme, because it will.

The advice gap is structural

Every party with a natural incentive to advise a buyer on this decision is also trying to be chosen. Implementation partners will tell you how to evaluate implementation partners, and it will look a great deal like their own strengths. Platform vendors point you to their certified partner list and stop there, because vetting the partner beyond certification isn't their job. Peers can offer an anecdote from their own last programme, one data point dressed up as a pattern. Few participants in this market are commercially independent of the decision itself, and that's the actual reason it gets so little real guidance.

Three ways authority actually gets structured

Picking the partner is only half the decision. The other half is what happens to authority once the contract's signed, and I've seen it structured three ways.

Partner-led is the most common: the partner runs process workshops, solution design, configuration, migration and testing, and the client supplies subject-matter experts and sign-off. It works fine for a contained, well-standardised implementation with an experienced internal owner. It gets fragile the moment “customer approval” is the only client-side control over architecture, because approving a design after it's already built is a far weaker position than shaping it while the options are still open.

Client-led flips the direction: an internal platform or architecture team sets the target state and directs the partner. This can work well where the client already has real Veeva depth and spare capacity. The risk here is quieter, a governance chart that shows internal ownership while the team underneath it doesn't have the time or platform depth to challenge what's actually being built, so the partner ends up making the calls anyway, just without anyone naming it that way.

Dual-control keeps the partner accountable for delivery execution and gives someone else, internal or independently appointed, authority over the decisions that cross workstream boundaries. In practice that's a short, specific list, things like cross-Vault data model changes, deviations from the standard lifecycle, or AI agent scope expansion, each with the evidence expected before sign-off and the standing authority to say no. That authority has to sit outside the partner's own delivery targets to mean anything, and it doesn't need a second team shadowing the first, just that short list, held by someone whose performance isn't measured on the same sprint.

For a contained, single-Vault rollout, partner-led is often the right call. For anything touching multiple Vaults, a recovery programme, or an AI-enabled Quality capability, dual-control is usually the safer structure, because the cost of an unowned decision compounds faster than the cost of the extra governance.

This matters more than it used to. A custom Vault AI agent runs under its own system-managed user record, with a security profile and a defined context, configured once by an admin. That's a real decision with real reach: what documents, fields and object relationships the agent can draw on to answer a question or take an action. It's also a decision that rarely gets revisited as the underlying process changes, and Veeva ships new agent capability roughly three times a year, so a security profile set at go-live keeps meeting more capability without anyone necessarily looking at it again. None of that shows up in a demo. It shows up the first time an agent answers with information nobody remembers deciding it should have.

Reading the SOW well protects you from what's on the page

The piece I wrote a few weeks ago on reading a SOW is still worth doing, and reading it well will catch things most buyers miss. But it only protects you from what's already on the page. It can't assign the fourth job, and it can't tell you whether the delivery structure you've agreed to gives anyone the standing to use that authority once the programme is under way. None of Veeva's tiers, and no line in the SOW, tell you which of the four jobs a partner is actually holding for you.

Before you sign, ask one question and watch how it gets answered: tell me about a time your delivery team wanted to hit a sprint milestone, and your architect held the line on the long-term design anyway. Who made that call, and what happened to the sprint? A smooth story about consensus doesn't prove architecture authority exists. It may just mean the governance has never been tested by a decision with a real cost attached.