A statement of work is a bet on what discovery hasn't found yet

A statement of work signed before discovery wraps is a fixed price attached to work nobody has actually inspected yet, and everyone in the meeting knows it. The sponsor wants a fixed number for the board. The consultant has quietly priced three unknowns as if they were known. I have watched the tell often enough to name it. Someone asks what happens if the legacy customization turns out to be worse than either side assumed, and the room moves straight on to the next line item instead of answering.

A safer number would not fix this. What fixes it is naming, inside the document itself, exactly what discovery has to confirm before the fixed-price phase can start. That single habit is what separates a statement of work that survives the first status call from one that gets rewritten by week six.

This guide is for admins and makers who are picking up their first few consulting engagements and are handed a sales deck with a number already on it. What follows is what actually protects both sides once the work starts, drawn from Dynamics 365 and Sales Cloud migrations without naming a client in the room.

Separate the phase you can price from the phase you can't

A fixed price belongs to work you can already describe. Moving configured fields, rebuilding a process flow, cutting over a set of reports. It does not belong to the count of custom plugins sitting on an on-premise Dynamics 365 instance, or the validation rules an admin who left two years ago built into a Sales Cloud org and never documented. Nobody in the sales cycle has opened those yet, and a number attached to them is a number attached to nothing.

I reviewed a statement of work once where the fixed price already covered migrating every opportunity and account record, plus every automation touching them, and discovery had not started. Three weeks into the project the team found a dozen workflow rules referencing a field that no longer existed anywhere in the source org. The change order that followed took two weeks to negotiate because nobody had agreed in advance what a change order even looked like.

Naming discovery as its own phase does the real work here, with its own deliverable and its own sign-off gate, and a rule that the fixed-price phase cannot begin until that gate closes. The client pays for discovery on a time basis or a small fixed fee, gets a real inventory back, and only then signs the number that depends on it.

What the discovery gate has to confirm before pricing locks

The gate deliverable does not need to be long. It needs to answer the questions that would otherwise surface as change orders in month two. This is what I ask a discovery phase to produce before anyone signs the build phase.

  • A count of every custom workflow, plugin, flow, and validation rule in scope, with a complexity rating on each one.
  • A data quality assumption stated in writing, naming who owns cleansing if the source data fails it.
  • Every integration touching the records in scope, with the system and the person who owns each endpoint.
  • The record volumes discovery actually measured, not the volumes the sales deck assumed.
  • The change-order rate and the number of business days it takes to approve one.
  • A named sponsor on the client side who signs the gate, with a date.

Rehearse the change order before you need it

A change-order clause that nobody has used is a clause that exists only on paper. I ask both teams to walk through submitting one during kickoff, using a made-up example. Discovery finds twice the number of Sales Cloud validation rules the deck assumed. Who writes the change order, who approves it, how many business days does that take. If nobody in the room can answer without checking, the clause is decorative and the first real change order will take longer than the work it is pricing.

The walkthrough also surfaces who actually has signing authority. More than once I have found that the person in the kickoff room cannot approve a change order over a certain dollar amount, and the real approver is someone who has not been in a single meeting. Better to learn that in week one than in week four, when the project is paying the team while the decision still sits unapproved.

Write the clause for when the legacy system is worse than assumed

Nobody wants to write this clause, because it states doubt about the deal inside the same document that is supposed to sell it. The clause protects the project when discovery finds that the legacy customization is not just undocumented but actively broken, built on a workflow engine nobody supports anymore or referencing an API version the target platform dropped. That finding changes the shape of the whole migration, and pretending it will not happen is how projects end up in a dispute instead of a change order.

The clause needs three things. A threshold that defines how bad a finding has to be before it triggers re-scoping rather than a routine change order. A named decision maker on each side who signs off on the re-scope within a set number of days. And a statement of what happens to the discovery work already paid for if the client decides not to proceed to build. Keeping a live migration risk register from day one gives both sides the paper trail this clause depends on, because the finding that triggers re-scoping should already be sitting in that register before the clause gets invoked.

Writing this clause is uncomfortable in the sales conversation. It is far more comfortable than the call where a client asks why the fixed price never mentioned the possibility that discovery might find something bad.

Promise a decision date, not a go-live date

The biggest mistake I made on an early statement of work was promising a specific go-live date in the kickoff deck before the data migration test had run a single time. The date felt safe because it matched the sales timeline, and it fell apart the moment the first test load revealed duplicate account records that had to be resolved by hand before anything else could move.

What I promise now instead is a decision date. By this date, we will have run one full mock migration, and by this date we will hand you a go-live estimate we can actually defend. That estimate might match the original hope. It might not. Either way the client gets a real number attached to real evidence instead of a date attached to a sales cycle.

The best statements of work read like they were written by someone who has been burned by exactly this kind of project before, because they were. The next time someone hands you a fixed go-live date to defend in a kickoff meeting, ask whose migration test it is based on. If the answer is none yet, you already know which date to promise instead.