Statement of Work for Dynamics 365 implementations

A Statement of Work (SOW) is the contractual document that defines what an implementation partner will deliver, when, for how much, and on what terms. Vague SOWs lead to disputes and cost overruns; well-structured SOWs hold both parties accountable while preserving flexibility for real-world adjustments.

Core SOW components.

• Scope of work — what's being done.
• Deliverables — specific outputs.
• Timeline — milestones and dates.
• Resources — staffing.
• Pricing — cost and payment terms.
• Acceptance criteria — how success is measured.
• Change management — process for scope changes.
• Assumptions — preconditions for the work.
• Risks — known risks and mitigations.
• Roles and responsibilities.

Each section deserves real attention; templates are starting points, not endpoints.

Scope of work. Explicit:

• Which Dynamics 365 modules?
• What functional areas?
• Which integrations?
• How many users / legal entities?
• Specific business processes to be implemented?

Out-of-scope items also listed — what's not included.

Deliverables. Tangible outputs:

• Functional Design Documents (FDDs).
• Technical Design Documents (TDDs).
• Configured environment.
• Custom code / extensions.
• Test scripts and results.
• Training materials.
• Cutover plan.
• Documentation.

Each deliverable described with:

• Description.
• Format.
• Acceptance criteria.
• Owner.

Timeline. Milestones:

• Project kick-off.
• Design phase completion.
• Build phase completion.
• UAT start / completion.
• Cutover.
• Go-live.
• Hypercare end.

Dates with dependencies; critical path identified.

Resource commitments.

• Named team members.
• Roles (architect, developer, business analyst).
• Allocation percentages.
• Duration of engagement.

Beware "team members to be named" — vague.

Pricing structure. Match to project type:

• Fixed price — clear deliverables, clear scope.
• Time and materials — exploratory, evolving scope.
• Milestone-based — payments tied to deliverable acceptance.
• Capped T&M — cost ceiling.

Each has implications; the right choice depends on certainty of scope.

Acceptance criteria. How is each deliverable judged complete?

• Document deliverables — reviewed and signed off.
• System deliverables — meets functional and non-functional requirements.
• Test deliverables — pass rate above threshold.

Specific criteria prevent "looks fine to us" disputes.

Change management process. Inevitable in any real project:

• Change request initiated by either party.
• Impact assessment — scope, schedule, cost.
• Approval — by both parties.
• Updated SOW addendum or change order.

Without documented process, every change is an argument.

Assumptions. Preconditions:

• "Customer provides timely access to subject matter experts."
• "Existing systems documentation is current."
• "Customer has data ready for migration by date X."

If assumptions don't hold, partner can invoke renegotiation. Document candidly.

Risks. Known risks:

• Data quality.
• Stakeholder availability.
• Integration complexity.
• Custom development scope.

For each, mitigation approach.

Roles and responsibilities. Who does what:

• Customer responsibilities — provide data, attend meetings, sign off.
• Partner responsibilities — deliver per scope.
• Joint responsibilities — testing, decisions.

A RACI chart often helps.

Governance structure.

• Steering committee membership.
• Reporting cadence.
• Issue escalation path.
• Decision authority.

Termination provisions.

• For convenience.
• For cause.
• Notice periods.
• Wind-down procedures.

Hopefully never invoked but essential.

Warranties and remedies.

• What partner warrants (deliverables work, free of defects).
• For how long (typically 30-90 days post-acceptance).
• Remedies for breach.

Liability limits.

• Cap on partner liability typically.
• Carve-outs (IP infringement, confidentiality, gross negligence).

Intellectual property.

• Who owns deliverables?
• Pre-existing IP retained by each party.
• Custom code typically client-owned.

Confidentiality. NDAs separate or integrated.

Common pitfalls.

• Vague scope. "Implementation of Dynamics 365 Sales" — what does that mean specifically?
• No change management. First change request becomes a fight.
• No assumptions documented. Partner assumed something; customer didn't; cost overrun.
• Pricing ambiguous. "Up to" or "approximately" — interpretation differs.
• Acceptance vague. Customer doesn't accept; project drags.
• No exit clauses. Either party stuck.

SOW negotiation.

• Lawyers and contracts teams involved.
• Take time; rushing produces problems.
• Push back on partner's standard terms where reasonable.
• Customer-friendly language matters.

Multi-phase engagements.

• Phase 1 SOW.
• Phase 2 SOW signed at appropriate point.
• Each phase has clear scope and outcomes.

Cleaner than mega-SOW covering everything.

Master Services Agreement + SOW. A common structure:

• MSA — overarching terms (liability, IP, confidentiality).
• SOWs under MSA — specific projects.

Reduces negotiation per project; useful for ongoing relationships.

Strategic positioning. The SOW is the project's commercial backbone. Time invested upfront pays back through clarity and accountability. Common mistake: signing weak SOWs to start work fast — leads to scope creep, disputes, and unhappy outcomes.

For decision-makers:

• Engage legal and procurement early.
• Be specific about scope and deliverables.
• Build in change management.
• Define acceptance objectively.
• Document assumptions candidly.

A well-crafted SOW protects both parties and sets the foundation for a productive partnership. Don't accept the partner's standard template without thoughtful review and negotiation — every clause has implications for the engagement.