Professional AI Scope of Work

Write an enforceable AI consulting SOW for a healthcare SMB client.

Introduction

30 Second Summary

Every AI consultant has had a client say "can you also do this while you're in there?" halfway through a project. Without a tight contract, that request becomes free work that eats your margin.

In this project, you will build a complete, executive-ready Statement of Work for a healthcare AI engagement. You will structure it to prevent scope creep and enforce accountability on both sides.

What You'll Build

You hand a 14-section SOW to a practice owner, walk them through it, and defend every line from "what does this cost?" to "what happens when we want to add something later?"

By the end of this project, you'll have:

  • A portfolio-ready GitHub repository containing a professional AI Statement of Work you could hand to a real client and defend every section.
  • Explicit exclusion language that gives you a contractual mechanism to redirect "just one more thing" requests into paid change orders.
  • Milestone-linked pricing where payments flow on deliverable acceptance rather than calendar dates, protecting your margin on a fixed-fee engagement.
  • Secret Mission: Write the executive summary that sells the SOW to a non-technical practice owner, plus a fully detailed change order for a realistic scope expansion request.

Are there any prerequisites?

You need Git installed, a GitHub account, and VS Code installed on Windows with PowerShell available. No cloud accounts or paid services are required.

Before We Start

Before We Start...

Before any hands-on work, this is the moment to commit to what you are building and why. You are the AI consultant scoping a healthcare AI engagement for Greenfield Family Medicine, and every section of the Statement of Work you write must be defensible in a real client meeting.

Set Up Your SOW Repository

A professional SOW lives in version control from the first keystroke. Clients request revisions, scope changes happen mid-engagement, and you need to compare versions to prove what was agreed at each milestone.

In this step, you will create a Git repository with the file structure for your SOW, populate the README with your engagement context, and make your first commit.

In this step, get ready to:
  • Create the project repository and file structure.
  • Populate the README with the engagement scenario and key skills.
  • Make your initial commit.
Create the repository and file structure

Every project folder starts on your Desktop so you can find it easily.

  • Press the Windows key to open your search bar.
  • Type PowerShell and press Enter to open it.
  • Move to your Desktop by running this command:
cd ~/Desktop
  • Create your project folder, move into it, and initialize a Git repository by running these commands:
mkdir project-04-ai-scope-of-work
cd project-04-ai-scope-of-work
git init

You should see a message saying Initialized empty Git repository confirming your repo is ready.

  • Create the four files your repository needs by running these commands:
New-Item -ItemType File -Name "README.md"
New-Item -ItemType File -Name "sow-greenfield-family-medicine.md"
New-Item -ItemType File -Name "scoring-rubric.md"
New-Item -ItemType File -Name "change-order-001.md"

What are these files for?

  • README.md describes the project and scenario for anyone viewing your repository.
  • sow-greenfield-family-medicine.md is the actual Statement of Work you will build section by section.
  • scoring-rubric.md holds a self-assessment rubric to score your SOW quality.
  • change-order-001.md demonstrates how you handle scope changes without losing margin.
  • Confirm all four files exist by running:
ls

You should see README.md, sow-greenfield-family-medicine.md, scoring-rubric.md, and change-order-001.md listed in the output.

Not seeing all four files?

Make sure you ran each New-Item command. If a file is missing, re-run the specific New-Item command for that file. Check for typos in the filename, especially the hyphen in change-order-001.md.

Help me troubleshoot my PowerShell file creation

Populate the README and scenario context

Your README is the first thing anyone sees when they open your repository. It sets the professional context for your SOW and summarizes the engagement scenario.

  • Open the project in VS Code by running this command:
code .

What does code . do?

The code . command tells VS Code to open the current folder as a workspace. The dot (.) means "this directory."

  • In the VS Code Explorer sidebar on the left, click README.md to open it.
  • Paste the following content into README.md to set up the project header, scenario description, and repository contents table:
# Project 4 of 24: Professional AI Scope of Work

## Greenfield Family Medicine - AI Implementation SOW

This repository contains a complete, executive-ready AI Statement of Work (SOW) developed as a portfolio project for AI consulting in the MSP/SMB space.

## Scenario

Greenfield Family Medicine is a 28-person multi-provider family practice clinic in suburban Texas seeking AI implementation to:
- Reduce physician documentation time by 40%
- Automate patient intake form processing
- Reduce 18% patient no-show rate through predictive scheduling

## Repository Contents

| File | Description |
|------|-------------|
| `sow-greenfield-family-medicine.md` | Complete executive-ready Statement of Work |
| `change-order-001.md` | Sample change order demonstrating scope change management |
| `scoring-rubric.md` | Self-assessment rubric for SOW quality |
| `README.md` | This file |

What does this content do?

  • The title and subtitle identify this as Project 4 in your series and name the client.
  • The scenario section gives any reviewer the business context in three bullet points.
  • The repository contents table helps visitors navigate your files quickly.
  • Below the Repository Contents table, add the key skills and engagement summary by pasting this content:
## Key Skills Demonstrated

- Translating discovery findings into contractual requirements
- Writing measurable acceptance criteria
- Structuring milestone-based pricing
- HIPAA-aware security requirements (technical consulting, not legal advice)
- Scope creep prevention through explicit exclusions and change control
- Risk identification and mitigation planning
- Stakeholder responsibility mapping

## Engagement Summary

- Type: Fixed-fee, 3-phase engagement
- Duration: 90 days (12 weeks)
- Value: $39,000
- Pricing Model: Milestone-based payments tied to deliverable acceptance

## Author

[Your Name] - AI Consultant Training Portfolio

What does this content do?

  • The Key Skills section tells recruiters and clients what capabilities this project demonstrates.
  • The Engagement Summary gives the engagement shape at a glance: fixed-fee, 3 phases, 90 days, $39,000.
  • The Author section is where you put your name when you push this to GitHub.
  • Save README.md by pressing Ctrl+S.
  • Check the Explorer sidebar. Your README.md should no longer show a dot indicator next to its name (the dot means unsaved changes).

VS Code not showing your files?

If the Explorer sidebar is empty, make sure you ran code . from inside the project-04-ai-scope-of-work folder. If you ran it from a different directory, close VS Code and re-run code . from within your project folder.

Help me fix my VS Code workspace

✔️ Awesome, I've got everything!

Great. Double check you saved the file, then move on to the initial commit.

ⓧ I'd like to double check the full code

Confirm your README.md contains both chunks in order:

  • Chunk 1: starts with # Project 4 of 24: Professional AI Scope of Work and ends with the Repository Contents table.
  • Chunk 2: starts with ## Key Skills Demonstrated and ends with [Your Name] - AI Consultant Training Portfolio.

Scroll up and confirm each section is present in your file. The complete file should have 6 markdown headings total.

Make your initial commit

With your file structure created and README populated, lock in this baseline with a commit. This gives you a clean starting point to compare against as you build each section of the SOW.

  • Switch back to your PowerShell terminal and stage all files, then commit by running these commands:
git add .
git commit -m "Initial project structure: AI SOW for Greenfield Family Medicine"

What do these commands do?

  • git add . stages all files in the current directory for commit.
  • git commit -m saves the staged changes as a snapshot with your message describing what changed.

Before you verify, predict: how many commits do you expect to see in the log, and what message should appear?

  • Confirm your commit by running:
git log --oneline

You should see exactly one commit with the message Initial project structure: AI SOW for Greenfield Family Medicine. In VS Code, the Explorer sidebar shows all four files.

Seeing 'nothing to commit' or an error?

If Git says there is nothing to commit, you may have already committed. Run git log --oneline to check. If you see your commit there, you are all set.

If Git asks you to set your name and email, run git config --global user.name "Your Name" and git config --global user.email "you@example.com" first, then re-run the commit command.

Help me fix my Git commit

Your repository structure is locked in. Next up, you will translate raw discovery notes into the measurable business objectives that open your SOW and prove you understood the client's pain.

Translate Discovery Into Business Objectives

Your repository is ready and your scenario is locked in. Now it is time to write the first real section of your SOW.

Raw discovery notes are not actionable requirements. If your SOW opens with technology ("deploy AI tools") instead of the business problem ("physicians lose 2 hours/day to documentation"), the client cannot evaluate whether you understood their pain. You have no measurable standard to prove you delivered value. In this step, you will translate interview findings into objectives a third party could verify.

In this step, get ready to:
  • Write the SOW document scaffold with header metadata and an executive summary placeholder.
  • Translate discovery findings into measurable business objectives with baselines, targets, and measurement methods.
  • Validate every objective against the "so what" test and commit to Git.
Write the problem statement from discovery findings

You received discovery findings from your kickoff meetings with Greenfield Family Medicine. These are your raw interview notes, and your job is to turn them into enforceable contract language.

Your discovery context (interview notes)

Treat the following as findings from your kickoff meetings with GFM:

  • 28 staff: 4 physicians, 2 NPs, 3 MAs, 8 front desk/admin, 2 billing, 1 practice manager, 1 IT contact, 7 clinical support.
  • Physicians spend approximately 2 hours per day on clinical documentation after hours ("pajama time").
  • Front desk manually enters patient intake forms averaging 15 minutes per patient.
  • 18% patient no-show rate, costing approximately $196,000 in annual lost revenue.
  • Currently on athenahealth EHR, no API integrations active.
  • Practice owner wants "AI to help" but has no specific technology requirements.
  • Clinic serves approximately 80-100 patients per day across all providers.
  • Budget: owner mentioned "around $40K" for the initial project, open to phased approach.

Your first task is to set up the document structure. The executive summary comes last (you will write it in the Secret Mission), so it gets a placeholder now.

  • In VS Code, open sow-greenfield-family-medicine.md from the Explorer sidebar.
  • Add the document header and Section 1 placeholder by pasting the following:
# AI Implementation Statement of Work
## Greenfield Family Medicine - AI-Powered Clinical Operations

SOW Reference: GFM-AI-2026-001
Prepared by: [Your Name], AI Consultant
MSP: [MSP Name]
Date: [Date]
Version: 1.0

---

## 1. Executive Summary

[To be completed]

---

What does this structure do?

The header block identifies the document formally. Reference numbers, version tracking, and preparation dates are standard on consulting deliverables because clients compare versions when negotiating changes.

The Executive Summary placeholder goes first because it is the first section a practice owner reads. You will write it last (in the Secret Mission) because you need the full SOW written before you can summarize it.

  • Save sow-greenfield-family-medicine.md.
  • You should see the document title and section heading rendered in the editor. The horizontal rules (---) separate sections visually.

Now write the core analytical section. Section 2.1 translates those raw discovery numbers into a single paragraph that names the business problem in measurable terms. Section 2.2 locks each problem to a specific baseline, target, and measurement method.

  • Below the last --- line, add Section 2 with the problem statement and measurable outcomes table:
## 2. Business Objectives

### 2.1 Problem Statement

Greenfield Family Medicine is a 28-person multi-provider family practice in suburban Texas experiencing operational strain from documentation overhead, manual data entry, and unpredictable patient scheduling. Physicians currently spend approximately 2 hours per day on clinical documentation after hours, front desk staff manually enter patient intake forms averaging 15 minutes per patient, and the clinic's 18% no-show rate creates approximately $196,000 in annual lost revenue.

### 2.2 Measurable Business Outcomes

| Objective | Baseline | Target | Measurement Method |
|-----------|----------|--------|-------------------|
| Reduce physician documentation time | 2 hours/day after-hours | 1.2 hours/day (40% reduction) | EHR time-tracking reports |
| Accelerate patient intake processing | 15 minutes manual entry/patient | Under 2 minutes/patient | Front desk time study |
| Reduce patient no-show rate | 18% | 12% or below | Scheduling system reports |

Why baselines and targets matter in a contract

Each row in the table does three things. The baseline proves you measured the current state (not guessed). The target gives the client a specific outcome to hold you accountable for. The measurement method tells both parties how to verify success without subjective interpretation.

Notice the problem statement names dollars ($196,000 lost revenue), hours (2 hours/day), and minutes (15 min/patient). These are the numbers a practice owner already feels. Starting with their pain in their language builds trust before any technical content appears.

  • Save the file.
  • You should see the markdown table rendered with clear column alignment in the editor.

Table not rendering correctly?

Make sure the pipe characters (|) line up and that the separator row uses dashes (|---|). Each row must have the same number of pipe-separated columns.

If you see raw text instead of a formatted table, install a Markdown preview extension or press Ctrl+Shift+V to open the VS Code Markdown preview.

Help me fix my markdown table formatting.

The primary KPIs are locked in. Now add broader success metrics that capture the engagement's overall impact beyond the three main targets.

  • Below the measurable outcomes table, add Section 2.3:
### 2.3 Success Metrics

- Physician satisfaction score improvement (measured via pre/post survey)
- Patient throughput increase of 10-15% within 6 months post-deployment
- ROI breakeven within 9 months of full deployment
- Staff adoption rate above 80% within 30 days of training

What separates success metrics from business outcomes?

Section 2.2 defines the contractual targets you are measured against. Section 2.3 captures broader indicators the client cares about but that depend on factors beyond your direct control (patient behavior, long-term adoption, ROI timing). Including them shows business maturity without making them acceptance criteria.

  • Save sow-greenfield-family-medicine.md.
  • Scroll through your file. You should see the full document header, the Section 1 placeholder, and a complete Section 2 with three subsections.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file before moving on.

ⓧ I'd like to double check the full code

Your file should contain these sections in order. Scroll up to confirm each is present:

  • Document header (title, subtitle, reference number, metadata).
  • Section 1: Executive Summary with [To be completed] placeholder.
  • Section 2.1: Problem Statement paragraph naming three measurable problems.
  • Section 2.2: Measurable Business Outcomes table with 3 rows, each having Objective/Baseline/Target/Measurement Method.
  • Section 2.3: Success Metrics with 4 bullet points.
Validate your objectives against the "so what" test

Before you commit, every measurable outcome in your table must pass four checks. If any objective fails, rewrite it until it passes.

  • Review each row in your Section 2.2 table against these criteria:
  • Has a specific baseline number (not "currently slow" or "too much time").
  • Has a specific target (not "improve" or "reduce" without a number attached).
  • Names the measurement method (not "we will know" or "it will be obvious").
  • Could be verified by a third party without subjective judgment.

Why this test matters for your margin

Vague objectives like "improve documentation efficiency" give the client room to argue you never delivered. Specific objectives like "reduce from 2 hours/day to 1.2 hours/day, measured by EHR time-tracking" give you a clear finish line. When you cross it, the milestone is complete and payment is due.

Commit your progress

Your business objectives section is complete. Lock it into version control so you have a clean checkpoint before building the scope and exclusions.

  • Commit your changes by running this command in the VS Code terminal:
git add .
git commit -m "Add business objectives: problem statement and measurable outcomes"

Before you run the next command, what do you expect to see? Think about how many files changed and how many lines you added.

  • Verify your commit by running:
git log --oneline

You should see two commits: your initial structure commit from Step 1 and the new business objectives commit you just made.

Only seeing one commit?

Make sure you saved sow-greenfield-family-medicine.md before running git add .. Unsaved changes in VS Code are not tracked by Git.

Run git status to check if you have uncommitted changes. If you see modified files, run the git add . and git commit commands again.

Help me troubleshoot my Git commit.

Now open your SOW file and read Section 2 aloud. Every objective has a number you could measure on day one (baseline) and a number you could verify at project end (target). If you see words like "improve," "better," or "optimize" without a number attached, the section is not ready.

Your business objectives are locked in with measurable targets. Next up, you will write the scope, exclusions, and deliverables. The exclusion list is the single most valuable section of any SOW because it gives you a contractual mechanism to block scope creep before it starts.

Define Scope, Exclusions, Deliverables, and Responsibilities

Your business objectives give the client confidence that you understood their pain. But objectives alone are a blank check. Without explicit boundaries, clients assume adjacent work is included.

The exclusion list is the single most valuable section of any SOW. It gives you a contractual mechanism to say "that is a great idea, and it falls outside our current scope, so let me send you a change order." In this step, you will write exclusions first, then define what is in scope, deliverables, assumptions, and responsibilities.

In this step, get ready to:
  • Write in-scope services by phase and an explicit exclusion list with 12+ items.
  • Define deliverables, assumptions, dependencies, and responsibility tables.
  • Scenario-test your exclusions against a realistic client email.
Write in-scope services and the exclusion list

Most consultants write deliverables first and skip exclusions entirely. That is backwards. A client who sees deliverables will assume adjacent work is included unless you explicitly state otherwise.

Why write exclusions before deliverables?

Exclusions are your contractual defense against scope creep. When a client asks "Can you also do X?", you point to the exclusion, acknowledge it is a good idea, and offer to scope it as a change order with its own timeline and cost.

Without that list, you are stuck arguing whether X was "implied" as part of the original engagement. That argument costs money and damages the relationship.

  • In VS Code, open sow-greenfield-family-medicine.md.
  • Below the Section 2 content, add a new heading ## 3. Scope of Work with a horizontal rule separator above it.
  • Write Section 3.1 (In-Scope Services) organized by the three project phases. Each phase lists the specific activities your team performs.

Structure your in-scope services using these three phases from the engagement plan:

  • Phase 1: Discovery and Assessment (Weeks 1-3) covers AI readiness assessment, data flow mapping, EHR integration analysis, vendor evaluation, security gap analysis, and stakeholder interviews.
  • Phase 2: Implementation (Weeks 4-9) covers AI documentation tool deployment (pilot with 2 providers), intake AI configuration, predictive scheduling integration, athenahealth API integration, staff training, and security controls.
  • Phase 3: Validation and Handoff (Weeks 10-12) covers acceptance testing, performance measurement, documentation delivery, knowledge transfer, and 30-day support transition.
  • Now write Section 3.2 (Out-of-Scope Exclusions). List at least 12 items that a practice manager might reasonably assume were included if you only listed in-scope items.

Start with the items most commonly "assumed included" by healthcare clients. Think about what sits adjacent to your in-scope work but would require different expertise, different timelines, or different risk profiles.

The assumption test for exclusions

For each exclusion, ask: "Would a practice manager reasonably assume this was included if I only listed in-scope items?" If yes, it belongs on the list. If no one would ever assume it was included, it is wasting space.

  • After your exclusions, write Section 3.3 (Deliverables) as a numbered table with columns for #, Deliverable Name, Format, and Due Date.
  • Number your deliverables D1 through D10. Every deliverable must be a named, countable thing with a specific format.

What makes a strong deliverable?

"A solution" is not a deliverable. "AI Readiness Assessment Report, PDF, 15-25 pages, End of Week 3" is. Each deliverable names what the client receives, what format it takes, and when they get it.

  • Save sow-greenfield-family-medicine.md.
  • Read through your Section 3.2 exclusions. Confirm you have at least 12 items and that each passes the assumption test.

Want to compare your Section 3 against a professional reference? Check below.

✔️ I'll try it first

Great. Make sure each phase in 3.1 has 5-6 specific activities, your exclusion list has 12+ items, and every deliverable in 3.3 has a format and due date.

ⓧ Let me check my work

Here is a professional reference for Section 3.1 (In-Scope Services):

### 3.1 In-Scope Services

Phase 1: Discovery and Assessment (Weeks 1-3)
- AI readiness assessment of existing infrastructure
- Data flow mapping for clinical documentation workflows
- EHR integration feasibility analysis (athenahealth)
- Vendor evaluation and recommendation (ambient AI documentation tools)
- Security and compliance gap analysis
- Stakeholder interviews (physicians, front desk, practice manager, IT)

Phase 2: Implementation (Weeks 4-9)
- AI ambient documentation tool deployment (pilot: 2 providers)
- Patient intake form digitization and AI extraction configuration
- Predictive scheduling model configuration and integration
- athenahealth API integration for data flow
- Staff training program delivery (role-based)
- Security controls implementation per HIPAA requirements

Phase 3: Validation and Handoff (Weeks 10-12)
- Acceptance testing against defined criteria
- Performance measurement against baseline metrics
- Documentation delivery (admin guide, user guides, runbooks)
- Knowledge transfer sessions
- 30-day post-deployment support transition

Here is the reference for Section 3.2 (Exclusions):

### 3.2 Out-of-Scope (Exclusions)

The following items are explicitly excluded from this engagement:

- Custom AI model development or fine-tuning
- EHR system migration or upgrade
- Hardware procurement or installation
- Network infrastructure changes
- Telehealth platform integration
- Patient portal redesign
- Billing/coding AI automation
- Ongoing managed services beyond the 30-day transition period
- Legal review of BAA or compliance documentation (client's legal counsel responsibility)
- HIPAA compliance certification or audit
- Multi-location rollout (this SOW covers the primary clinic location only)
- Training of patient-facing AI chatbots or virtual assistants

And the reference for Section 3.3 (Deliverables):

### 3.3 Deliverables

| # | Deliverable | Format | Due |
|---|-------------|--------|-----|
| D1 | AI Readiness Assessment Report | PDF, 15-25 pages | End of Week 3 |
| D2 | Vendor Recommendation with Comparison Matrix | PDF + spreadsheet | End of Week 3 |
| D3 | Security and Compliance Gap Analysis | PDF | End of Week 3 |
| D4 | Deployed AI Documentation Tool (pilot) | Live system | End of Week 6 |
| D5 | Patient Intake AI Configuration | Live system | End of Week 7 |
| D6 | Predictive Scheduling Integration | Live system | End of Week 9 |
| D7 | Staff Training Materials | PDF + video recordings | End of Week 9 |
| D8 | Admin Guide and Runbook | PDF, 20-30 pages | End of Week 11 |
| D9 | Acceptance Test Results Report | PDF | End of Week 11 |
| D10 | Knowledge Transfer Sessions (3x 90-min) | Live sessions + recordings | End of Week 12 |

Struggling to come up with 12 exclusions?

Think about what sits one step away from each in-scope item. You are deploying AI documentation tools, so clients might assume custom model training is included. You are integrating with athenahealth, so they might assume an EHR migration is on the table. You are training staff, so they might expect patient-facing chatbot training too.

Help me brainstorm more exclusions for my healthcare AI SOW.

Write assumptions, dependencies, and responsibilities

Your scope says what you will do. Assumptions and dependencies say what must be true for your plan and price to hold. If any assumption turns out to be false, you have a contractual basis for a change order.

  • Below Section 3, add Section 4 (Assumptions and Dependencies) with three subsections.
  • Write Section 4.1 (Assumptions): list 7 conditions that must be true for the engagement to succeed as planned. These include athenahealth API access, internet reliability, physician willingness, Wi-Fi coverage, infrastructure readiness, practice manager authority, and stable patient volume.
  • Write Section 4.2 (Dependencies) as a table with columns for Dependency, Owner, and Required By. List every input you need from GFM, who provides it, and when.
  • Write Section 4.3 (Dependency Impact): one paragraph stating what happens when a dependency is late. Include a threshold for timeline shift and a trigger point for a formal change order.

Why name owners and dates on dependencies?

A dependency without an owner is a hope. A dependency without a deadline is a someday. When a client provides athenahealth API credentials two weeks late, your timeline shifts. The dependency table makes that consequence explicit before it happens, not after.

  • Now add Section 7 (Roles and Responsibilities) with two tables.
  • Write Section 7.1 (Client Responsibilities) listing 6 GFM roles: Project Sponsor, Practice Manager, Medical Director, IT Contact, Legal Counsel, and Pilot Physicians. Name each role's specific responsibility.
  • Write Section 7.2 (Vendor Responsibilities) listing 4 roles: Project Lead, Implementation Engineer, Training Specialist, and Security Advisor.
  • Save sow-greenfield-family-medicine.md.

Why skip from Section 4 to Section 7?

Sections 5 and 6 cover Technical Requirements and Security/Compliance. You will write those in the next step. Section 7 (Responsibilities) logically follows Section 4 (Dependencies) because both define who is accountable for what.

Ready to compare your Sections 4 and 7 against a professional reference?

✔️ I'll try it first

Confirm that every dependency in 4.2 has a named owner (a specific GFM role, not "GFM") and a specific deadline (a week number, not "as soon as possible"). Your Section 4.3 must state both a grace period and a change order trigger.

ⓧ Let me check my work

Here is the reference for Section 4 (Assumptions and Dependencies):

### 4.1 Assumptions

- GFM's athenahealth instance supports API access for third-party integrations
- Clinic has reliable internet connectivity (minimum 100 Mbps symmetric)
- Physicians are willing to participate in pilot and provide feedback
- Existing Wi-Fi covers all exam rooms for ambient documentation
- GFM's current IT infrastructure meets minimum requirements for AI tool deployment
- Practice manager has authority to approve workflow changes
- Patient volume remains within normal operating range during implementation

### 4.2 Dependencies (Client-Provided)

| Dependency | Owner | Required By |
|------------|-------|-------------|
| athenahealth admin access and API credentials | GFM IT / Practice Manager | Week 1 |
| Designated project sponsor with sign-off authority | GFM | Week 1 |
| Staff availability for interviews (6 hours total) | GFM Practice Manager | Weeks 1-2 |
| Exam room access for technical assessment | GFM Office Manager | Week 2 |
| Physician pilot participants identified (2) | GFM Medical Director | Week 3 |
| Staff availability for training (4 hours/role) | GFM Practice Manager | Weeks 8-9 |
| Legal counsel review of BAA | GFM Legal | Weeks 2-4 |
| Approval of vendor recommendation | GFM Sponsor | End of Week 4 |

### 4.3 Dependency Impact

If a client dependency is not met within 5 business days of the required date, the project timeline will shift by the equivalent delay period. Timeline adjustments exceeding 10 business days require a formal change order.

And the reference for Section 7 (Roles and Responsibilities):

### 7.1 Client Responsibilities (Greenfield Family Medicine)

| Role | Responsibility |
|------|---------------|
| Project Sponsor (Practice Owner) | Final sign-off on deliverables, budget approval, escalation point |
| Practice Manager | Day-to-day coordination, staff scheduling, workflow decisions |
| Medical Director | Clinical workflow approval, physician pilot oversight |
| IT Contact | System access, credentials, infrastructure support |
| Legal Counsel | BAA review, compliance determination, risk acceptance |
| Pilot Physicians (2) | Active participation in pilot, feedback, workflow adoption |

### 7.2 Vendor Responsibilities (MSP/Consultant)

| Role | Responsibility |
|------|---------------|
| Project Lead / AI Consultant | SOW delivery, technical recommendations, vendor evaluation, implementation oversight |
| Implementation Engineer | Technical deployment, integration configuration, testing |
| Training Specialist | Staff training delivery, materials development |
| Security Advisor | Security controls, compliance gap analysis, vendor security review |
Commit and scenario-test your scope

Your scope is only as strong as its ability to deflect a real client request. Time to test it.

  • Commit your progress by running these commands in your PowerShell terminal:
git add .
git commit -m "Add scope, exclusions, deliverables, assumptions, dependencies, responsibilities"

Now read the following simulated client email. This is the kind of message you will receive during a real engagement.

Simulated client email from the GFM Practice Manager

"This is great! While you're in there setting up the AI documentation, can you also configure it to send automated billing codes to our clearinghouse? And my office manager wants to know if you'll be training the AI on our specific patient population. Oh, and we're thinking about opening a second location in Q2 - can we plan for that too?"

Before you check, predict: does your Section 3.2 have a specific, named exclusion that addresses each of these three requests?

  • Open your Section 3.2 and find the exclusion that covers automated billing codes.
  • Find the exclusion that covers training AI on a specific patient population.
  • Find the exclusion that covers the second location.

Each request should map to a named exclusion. "Billing/coding AI automation" covers the first. "Custom AI model development or fine-tuning" covers training on their specific data. "Multi-location rollout" covers the second clinic.

How to respond to this email professionally

You never say "no." You say: "Great ideas. Items 1 and 2 are listed in our exclusions (Section 3.2), and item 3 is scoped to primary clinic only. I would be happy to prepare change orders for any of these with timeline and cost impact. Want me to start with the billing integration?"

  • If any of the three requests is not covered by a specific exclusion in your Section 3.2, add it now, save the file, and amend your commit by running:
git add .
git commit --amend -m "Add scope, exclusions, deliverables, assumptions, dependencies, responsibilities"

What does git commit --amend do?

The --amend flag updates your most recent commit instead of creating a new one. This keeps your commit history clean when you catch something immediately after committing.

  • Verify your commit by running:
git log --oneline

You should see your new commit with the message about scope, exclusions, deliverables, assumptions, dependencies, and responsibilities.

Can't find an exclusion that matches one of the requests?

Make sure you have "Billing/coding AI automation" for the billing request, "Custom AI model development or fine-tuning" for the training-on-patient-data request, and "Multi-location rollout (this SOW covers the primary clinic location only)" for the second location request. The parenthetical on the multi-location exclusion makes the boundary crystal clear.

Help me verify my exclusion list covers common healthcare AI scope creep requests.

Your scope is now defensible. Every in-scope service has boundaries. Every exclusion blocks a common assumption. Every deliverable is named and dated. Next, you will build the security and compliance section that demonstrates real technical depth for a healthcare engagement.

Build Security, Compliance, and Technical Requirements

Your scope, exclusions, and responsibilities are locked in. Now you need to address the section that separates professional healthcare AI consultants from generalists: security and compliance.

For healthcare AI engagements, vague security language creates direct regulatory exposure. A SOW that says "we will comply with HIPAA" is meaningless because it is not specific enough to implement or verify. You must name the specific data types, where they flow, what controls apply, and who is responsible for what.

In this step, get ready to:
  • Write technical infrastructure and integration requirements.
  • Build a data classification table and HIPAA-specific controls.
  • Establish the critical legal distinction between technical consulting and legal advice.
Write the data classification and security requirements

Section 5 names what the clinic's infrastructure must provide. Section 6 names exactly what data the AI tools touch, how it is classified, and what controls protect it.

  • In sow-greenfield-family-medicine.md, add Section 5 (Technical Requirements) below Section 4. Write the following after the Section 4 closing divider:
## 5. Technical Requirements

### 5.1 Infrastructure Requirements

- athenahealth EHR with API access enabled
- Internet connectivity: minimum 100 Mbps symmetric, 99.5% uptime
- Wi-Fi coverage in all exam rooms (for ambient documentation devices)
- Workstations: Windows 10/11 or macOS, minimum 8GB RAM, modern browser
- Mobile devices for physician ambient capture (iOS 16+ or Android 13+)

### 5.2 Integration Points

- athenahealth Marketplace API (patient records, scheduling, documentation)
- AI vendor API endpoints (vendor-specific, determined in Phase 1)
- Clinic scheduling system (integrated via athenahealth)

What does this section do?

Section 5 turns your assumptions from Section 4 into hard requirements. If the clinic's internet drops below 100 Mbps or their Wi-Fi does not cover exam rooms, you now have a documented basis for a change order or timeline shift.

Each requirement is specific enough that an implementation engineer could verify it on day one without asking you what you meant.

  • Save sow-greenfield-family-medicine.md.
  • Scroll through Section 5 in VS Code. You should see two subsections with bullet lists naming specific versions, speeds, and platforms.
  • Now add a divider and begin Section 6. Write the section header and the data classification table directly below Section 5:
---

## 6. Security and Compliance

### 6.1 Data Classification

| Data Type | Classification | Handling Requirement |
|-----------|---------------|---------------------|
| Patient visit audio | PHI - High Sensitivity | Encrypted at rest and in transit, no local storage, processed in HIPAA-compliant environment |
| Clinical notes (draft and final) | PHI - High Sensitivity | Generated and stored within HIPAA-compliant infrastructure, BAA required with AI vendor |
| Patient intake forms | PHI - Medium Sensitivity | Encrypted processing, no retention beyond extraction, audit logged |
| Scheduling data | PHI - Low Sensitivity | Encrypted in transit, de-identified where possible for predictive modeling |
| Model training data | Prohibited | No GFM patient data shall be used to train AI vendor models |

Why classify data before writing controls?

Data classification drives every security decision that follows. "PHI - High Sensitivity" means encryption everywhere, BAA required, no local storage. "PHI - Low Sensitivity" allows de-identification for modeling. Without this table, your controls are either overkill (expensive) or insufficient (risky).

The "Prohibited" row is especially important. It preempts the vendor saying "we improve our models with customer data" by making a contractual prohibition explicit.

  • Save the file and confirm you see a five-row table with three columns under Section 6.1.
  • Below Section 6.1, write Section 6.2 naming the specific HIPAA controls this engagement requires:
### 6.2 HIPAA Compliance Requirements

- Business Associate Agreement (BAA) executed with all AI vendors processing PHI prior to any data access
- Minimum Necessary standard applied to all AI tool data access
- Access controls: role-based, least-privilege, logged
- Audit logging for all PHI access, creation, modification, and deletion
- Encryption: AES-256 at rest, TLS 1.2+ in transit
- Data retention: aligned with GFM's existing retention policy (minimum 7 years for medical records)
- Breach notification: per HIPAA Breach Notification Rule (60 days to HHS, immediate to GFM)
- Right to audit: GFM retains the right to audit AI vendor compliance annually

Why name specific encryption standards?

"AES-256 at rest, TLS 1.2+ in transit" is verifiable. A third-party auditor can check whether the vendor's infrastructure meets this standard without interpretation. "Appropriate encryption" is not verifiable because everyone has a different definition of appropriate.

The same principle applies to every bullet. "Role-based, least-privilege, logged" names three testable properties. "Proper access controls" names zero.

  • Below Section 6.2, write Sections 6.3 (Vendor Security Requirements) and 6.4 (Consultant Obligations):
### 6.3 Vendor Security Requirements

All AI vendors recommended and deployed must:
- Hold current SOC 2 Type II certification
- Execute a HIPAA BAA with GFM
- Provide data processing addendum specifying subprocessors
- Confirm no use of customer data for model training without explicit consent
- Support data deletion upon engagement termination
- Maintain HITRUST CSF certification or equivalent
- Provide incident response SLA (notification within 24 hours)

### 6.4 Consultant Obligations

- No PHI stored on consultant devices or personal systems
- All access to GFM systems through approved, encrypted channels only
- Background check documentation provided upon request
- Consultant operates under MSP's BAA with GFM

What is SOC 2 Type II?

SOC 2 Type II is an independent audit that verifies a vendor's security controls have been operating effectively over a 6-12 month period. Type I only confirms controls exist at a single point in time. Type II proves they work consistently.

Requiring this from AI vendors is the gold standard for healthcare consulting. It shifts the verification burden to an independent auditor rather than relying on vendor self-assessment.

  • Save sow-greenfield-family-medicine.md.
  • Scroll through Section 6. You should now see four subsections (6.1 through 6.4) with the data classification table, eight HIPAA requirements, seven vendor requirements, and four consultant obligations.

Table not rendering correctly in preview?

Make sure every row in your data classification table has exactly three pipe-separated columns. Missing a pipe character on one row breaks the entire table rendering. Check that your header separator row has three |---| sections.

If you see raw markdown characters instead of a formatted table, press Ctrl+Shift+V in VS Code to open Markdown Preview and confirm the table structure.

Help me fix my markdown table formatting in my SOW file.

Write the critical legal distinction

This final subsection is short but arguably the most important sentence in your entire security section. It defines the boundary of your professional responsibility.

  • Below Section 6.4, add Section 6.5 (Important Distinction):
### 6.5 Important Distinction

This SOW addresses technical consulting requirements for security implementation. It does not constitute legal advice or compliance certification. GFM's legal counsel is responsible for:
- Final BAA review and execution
- HIPAA compliance determination
- Regulatory interpretation
- Risk acceptance decisions

Why does this distinction protect you?

You are a technical consultant, not a lawyer. If your SOW blurs that line, a client could argue you certified their HIPAA compliance. That creates liability exposure you are not qualified or insured to carry.

This clause explicitly names what falls under the client's legal counsel: BAA execution, compliance determination, regulatory interpretation, and risk acceptance. You recommend technical controls. They accept (or reject) the risk.

  • Save sow-greenfield-family-medicine.md.
  • Scroll to the bottom of Section 6. You should see five subsections (6.1 through 6.5) with Section 6.5 ending on four bullet points naming specific legal counsel responsibilities.
Commit your security section

Your security and compliance sections are complete. Time to commit this progress to version control.

  • Commit your work by running this command in PowerShell:
git add .
git commit -m "Add security, compliance, technical requirements with legal distinction"

Before you check the result, ask yourself: could a third party audit GFM's AI implementation against your Section 6 without ever calling you to ask what you meant?

  • Read through Section 6 from top to bottom. Confirm that every requirement names a specific, verifiable control.

If you see phrases like "appropriate security measures" or "adequate protection" anywhere, replace them with named standards. "AES-256 at rest, TLS 1.2+ in transit" passes the audit test. "Appropriate encryption" does not.

Seeing vague language in your section?

Apply this test to every bullet in Section 6.2 and 6.3: can someone verify compliance with this requirement by running a check or reviewing documentation, without asking you to define your terms? If not, rewrite the bullet with a named standard, a specific threshold, or a countable property.

Help me identify vague language in my SOW security section that should be replaced with specific, verifiable requirements.

✔️ Awesome, I've got everything!

Great. Double check you have saved your file. Your SOW now contains Sections 1 (placeholder), 2, 3, 4, 5, 6, and 7.

ⓧ I'd like to double check the full code

Scroll through your sow-greenfield-family-medicine.md file and confirm these sections appear in order:

  • Section 5 with subsections 5.1 (Infrastructure Requirements) and 5.2 (Integration Points).
  • Section 6 with subsections 6.1 (Data Classification table with 5 rows), 6.2 (HIPAA Compliance Requirements with 8 bullets), 6.3 (Vendor Security Requirements with 7 bullets), 6.4 (Consultant Obligations with 4 bullets), and 6.5 (Important Distinction with 4 legal counsel responsibilities).
  • Section 7 (Roles and Responsibilities) still present below Section 6.

If any subsection is missing, scroll up through this step and locate the relevant code block to add it.

Your SOW now has the section that wins healthcare AI deals. Next up, you will build the timeline, pricing, and change control mechanisms that protect your margin when scope pressure hits.

Build Timeline, Pricing, Risks, Acceptance, and Change Control

Your SOW now has defined scope, explicit exclusions, and security requirements. But a SOW with defined scope and no pricing logic is still a blank check for scope creep.

The $39,000 estimate means nothing until payments are locked to specific milestones with acceptance gates, and the client knows exactly what triggers additional cost. This step is where margin protection lives.

In this step, get ready to:
  • Build a timeline with milestone-linked payment gates that tie money to deliverable acceptance.
  • Write acceptance criteria, change control triggers, and a risk register.
  • Complete the SOW with governance, termination, IP, and signatures sections.
Build timeline, milestones, and pricing

The critical principle here: money flows when work is accepted, not when time passes. Every dollar in your fee structure must trace to a milestone, which traces to specific deliverables, which have specific acceptance criteria.

  • In sow-greenfield-family-medicine.md, scroll to the bottom of Section 7 and add Section 8 (Timeline and Milestones) with the following content:
---

## 8. Timeline and Milestones

### 8.1 Project Timeline

| Phase | Duration | Dates | Key Activities |
|-------|----------|-------|----------------|
| Phase 1: Discovery | Weeks 1-3 | [Start] - [+3 weeks] | Assessment, vendor eval, security analysis |
| Phase 2: Implementation | Weeks 4-9 | [+4 weeks] - [+9 weeks] | Deployment, integration, training |
| Phase 3: Validation | Weeks 10-12 | [+10 weeks] - [+12 weeks] | Testing, documentation, handoff |

### 8.2 Milestones and Payment Gates

| Milestone | Criteria | Payment |
|-----------|----------|--------|
| M1: Project Kickoff | SOW executed, access granted, kickoff completed | $7,800 (20%) |
| M2: Discovery Complete | D1, D2, D3 delivered and accepted | $9,750 (25%) |
| M3: Implementation Complete | D4, D5, D6, D7 deployed and operational | $13,650 (35%) |
| M4: Final Acceptance | D8, D9, D10 delivered, acceptance criteria met | $7,800 (20%) |
| Total | | $39,000 |

Why milestone-based payments?

Each milestone (M1-M4) is gated by specific deliverable acceptance, not by a calendar date. If the client delays providing dependencies and the timeline slips, your payment triggers are still tied to completion of defined work.

Notice how M2 references D1, D2, D3 from Section 3.3. This cross-referencing is what makes the SOW enforceable. A payment tied to "end of Week 3" gives the client leverage to withhold payment over calendar disputes.

  • Directly below Section 8, add Section 9 (Pricing and Payment Terms) starting with the fee structure and inclusions:
---

## 9. Pricing and Payment Terms

### 9.1 Fee Structure

This engagement is priced as a fixed-fee engagement.

| Component | Amount |
|-----------|--------|
| Phase 1: Discovery and Assessment | $11,700 |
| Phase 2: Implementation | $19,500 |
| Phase 3: Validation and Handoff | $7,800 |
| Total Fixed Fee | $39,000 |

### 9.2 What the Fee Includes

- All consultant labor (estimated 260 hours across engagement)
- Staff training delivery (up to 4 sessions, 2 hours each)
- Documentation and deliverables
- 30-day post-deployment support (email/phone, 4-hour response SLA)

Why break out the fee by phase?

Phase-level pricing gives the client transparency on where their money goes. It also gives you an internal check: at $150/hour blended rate, Phase 2 at $19,500 covers roughly 130 hours. If your implementation plan requires more, the scope is too large for the price.

  • Continue Section 9 by adding what the fee does NOT include, payment terms, and the pricing analysis:
### 9.3 What the Fee Does Not Include

- AI vendor software licensing fees (estimated $800-$2,500/month, billed directly to GFM by vendor)
- Hardware purchases (ambient documentation devices, estimated $3,000-$5,000)
- Additional training sessions beyond 4 ($750/session)
- Work outside defined scope (requires change order)
- Travel expenses beyond 50-mile radius ($0.67/mile + actual lodging)

### 9.4 Payment Terms

- Invoices issued upon milestone completion
- Payment due within 30 days of invoice
- Late payment: 1.5% monthly on overdue balance
- Work may be paused if payment is more than 15 days overdue

### 9.5 Pricing Analysis

The $39,000 fixed fee is based on:
- Blended consultant rate: $150/hour
- Estimated 260 hours total effort
- 10% margin buffer for contingency within defined scope
- Comparable market rate for healthcare AI consulting engagements of similar scope

What does the pricing analysis protect?

Section 9.5 forces you to critically evaluate your own estimate. At $150/hour across 260 hours, this is exactly $39,000. Fixed-fee means you absorb overruns within scope. If Phase 2 runs 20% over estimated hours, that is $3,900 out of your margin.

This is precisely WHY tight exclusions (Section 3.2) and change control (coming next) are non-negotiable. Every hour of unscoped work you absorb comes directly from your profit.

  • Save sow-greenfield-family-medicine.md.
  • Scroll through Sections 8 and 9. Confirm that every milestone in Section 8.2 references specific deliverable numbers (D1-D10) from Section 3.3, and that the four milestone payments sum to $39,000.

Numbers not adding up?

Double check that M1 ($7,800) + M2 ($9,750) + M3 ($13,650) + M4 ($7,800) = $39,000. Also confirm Phase fees in Section 9.1 sum to $39,000: $11,700 + $19,500 + $7,800.

Note that milestone payments and phase fees are structured differently. Milestones are payment triggers (when money flows). Phase fees are cost allocation (where the work lives). Both must total $39,000 but they divide it differently.

Help me understand the difference between milestone payments and phase fees in my SOW.

Write acceptance criteria, change control, and risk register

Acceptance criteria define what "done" means in objective, testable terms. Change control defines what triggers additional cost. Together, they prevent the two most common margin killers: indefinite revision cycles and unbilled scope additions.

  • Below Section 9, add Section 10 (Acceptance Criteria) with the general process and deliverable-specific criteria:
---

## 10. Acceptance Criteria

### 10.1 General Acceptance Process

- Consultant delivers completed deliverable with notification
- Client has 10 business days to review and accept or provide written objection
- If objection received: consultant has 5 business days to remediate
- If no response within 10 business days: deliverable is deemed accepted
- Maximum 2 revision cycles per deliverable; additional revisions via change order

### 10.2 Deliverable-Specific Acceptance Criteria

| Deliverable | Acceptance Criteria |
|-------------|--------------------|
| D1: AI Readiness Assessment | Covers all 6 assessment dimensions, includes current-state findings, identifies gaps, provides prioritized recommendations |
| D4: AI Documentation Tool (pilot) | Successfully generates draft clinical notes for 2 pilot physicians over 5 consecutive business days with less than 20% physician edit rate |
| D5: Patient Intake AI | Processes intake forms with 95% field extraction accuracy on a 50-form test set |
| D6: Predictive Scheduling | Generates no-show risk scores for scheduled appointments; initial accuracy measured against 30-day historical data |
| D8: Admin Guide | Covers all deployed systems, includes troubleshooting for top 10 support scenarios, validated by IT contact |

What is a deemed-acceptance clause?

The deemed-acceptance clause ("if no response within 10 business days, deliverable is deemed accepted") prevents a client from indefinitely stalling. Without it, a client who neither accepts nor objects can freeze your payment gate forever.

The 2-revision-cycle limit is equally important. Without it, a client can request infinite minor edits, each one technically "within scope" but collectively consuming your margin. Revision 3 and beyond trigger a change order.

  • Add Section 11 (Change Control) with the process, triggers, and minor adjustment carve-outs:
---

## 11. Change Control

### 11.1 Change Control Process

1. Change requested by either party in writing (email acceptable)
2. Consultant provides Change Order within 5 business days including: description of requested change, impact on scope, timeline, and budget, revised deliverables if applicable, additional cost if applicable
3. Client approves or declines Change Order in writing
4. No work on changed scope begins until Change Order is signed by both parties

### 11.2 Change Order Triggers

A change order is required when:
- Client requests work not listed in Section 3.1
- Discovery reveals environment materially different from assumptions in Section 4.1
- Client dependency delay exceeds 10 business days
- Vendor recommended in Phase 1 is rejected, requiring re-evaluation
- Regulatory change impacts security requirements during engagement
- Additional clinic locations are added to scope
- Additional staff training sessions are requested beyond the included 4

### 11.3 Minor Adjustments (No Change Order Required)

- Schedule shifts of 5 business days or less due to mutual agreement
- Clarifications to deliverable format that do not change content scope
- Substitution of equivalent staff roles with equal or greater qualification

Why include minor adjustment carve-outs?

Section 11.3 prevents the change control process from becoming adversarial. If every 2-day schedule slip requires a formal change order, the client stops communicating openly. The carve-outs show you are reasonable while keeping the hard boundaries on scope and cost.

Notice how each trigger in Section 11.2 cross-references a specific SOW section. This is not accidental. When a client says "can you also do X," you point to Section 3.1 (not in scope), then to Section 11.2 (triggers a change order), then offer to scope it. The SOW does the heavy lifting.

  • Add Section 12 (Risk Register) with 8 identified risks:
---

## 12. Risk Register

| # | Risk | Likelihood | Impact | Mitigation |
|---|------|-----------|--------|------------|
| R1 | athenahealth API does not support required integration | Medium | High | Phase 1 includes API feasibility assessment before commitment |
| R2 | Physician adoption resistance | Medium | Medium | Pilot approach with champions, phased rollout, training investment |
| R3 | AI vendor does not execute BAA | Low | Critical | Vendor eliminated from consideration; BAA is a hard requirement |
| R4 | Patient data exposed during implementation | Low | Critical | No real PHI used in testing until security controls verified; synthetic data for initial config |
| R5 | Timeline delay due to client dependencies | Medium | Medium | Dependency tracking with 5-day escalation; timeline shift clause in Section 4.3 |
| R6 | AI tool accuracy does not meet acceptance threshold | Medium | High | Defined acceptance criteria with remediation period; vendor SLA for accuracy improvements |
| R7 | Scope creep from stakeholder requests | High | Medium | Explicit exclusions list, change order process, regular scope review in status meetings |
| R8 | Staff turnover during implementation | Low | Medium | Documentation and training materials designed for knowledge transfer to new staff |

What makes a risk register valuable?

Each risk links its mitigation to a specific mechanism you already built into the SOW. Risk R7 (scope creep) points to the exclusions list AND the change order process. Risk R5 (dependency delays) points to Section 4.3's timeline shift clause.

This cross-referencing proves that your SOW is not a collection of disconnected sections. It is an interlocking system where each part reinforces the others.

  • Save sow-greenfield-family-medicine.md.
  • Review your risk register. Confirm that R7 (Scope creep) is rated High likelihood. If any risk does not name a specific mitigation mechanism from another SOW section, revise it now.

Table formatting broken in VS Code?

Markdown tables require the header separator row (the row of dashes and pipes). Make sure every table has exactly one separator row between the header and the data rows.

If columns look misaligned in the editor, that is purely cosmetic. The markdown will render correctly. You can install a Markdown preview extension to see formatted output.

Help me fix my markdown table formatting in VS Code.

Write governance, termination, and IP sections, then commit

The final sections define how the engagement is managed day-to-day, what happens if either party wants out, and who owns the work product. These sections are often boilerplate, but getting them wrong creates real legal exposure.

  • Add Section 13 (Support and Transition) below the risk register:
---

## 13. Support and Transition

### 13.1 Post-Deployment Support (Included)

- 30 calendar days following M4 acceptance
- Email and phone support, Monday-Friday, 8am-5pm CT
- 4-hour response SLA for critical issues
- 1 business day response for non-critical issues
- Up to 10 support tickets included

### 13.2 Ongoing Support (Not Included - Separate Agreement)

After the 30-day included support period, GFM may engage the MSP under a separate Managed AI Services agreement. This is not part of the current SOW and will be quoted separately if requested.

### 13.3 Transition Requirements

At engagement conclusion, the following will be transferred to GFM:
- All credentials and admin access to deployed AI tools
- Complete documentation package (D8)
- Training recordings
- Vendor contact information and escalation paths
- Configuration backup files

Why cap included support?

The 30-day window and 10-ticket cap prevent post-project support from becoming indefinite free labor. Section 13.2 explicitly names ongoing support as a separate agreement. Without this boundary, clients treat you as on-call staff long after the engagement ends.

  • Add Section 14 (Terms and Governance) with all four subsections:
---

## 14. Terms and Governance

### 14.1 Governance

- Weekly status meetings (30 minutes) during active phases
- Bi-weekly steering committee with Project Sponsor (as needed)
- Status reports delivered via email every Friday
- Escalation path: Project Lead > MSP Director > Practice Owner

### 14.2 Confidentiality

All information exchanged during this engagement is treated as confidential per the existing MSA between [MSP Name] and Greenfield Family Medicine.

### 14.3 Termination

- Either party may terminate with 15 business days written notice
- Upon termination: work product completed to date is delivered to GFM
- Payment due for all completed milestones plus pro-rated work on current milestone
- GFM retains all work product and deliverables produced

### 14.4 Intellectual Property

- All custom deliverables created for GFM are owned by GFM
- Consultant pre-existing frameworks, templates, and methodologies remain consultant property
- GFM receives perpetual license to use any embedded consultant IP in delivered work product
  • Finally, add the Signatures block at the very end of the file:
---

## Signatures

| | Client | Vendor |
|--|--------|--------|
| Name | _________________ | _________________ |
| Title | _________________ | _________________ |
| Date | _________________ | _________________ |
| Signature | _________________ | _________________ |

This Statement of Work is governed by the Master Services Agreement dated [DATE] between [MSP Name] and Greenfield Family Medicine.

What does the IP section protect?

Section 14.4 solves a common consulting dispute. Custom work (the assessment, the runbook) belongs to GFM. But your reusable frameworks, templates, and methodologies remain yours. You grant GFM a perpetual license to use them in the delivered work, but you can reuse those same frameworks with other clients.

Without this clause, a client could argue that everything you produced during the engagement is their exclusive property, preventing you from using your own methodology elsewhere.

  • Save sow-greenfield-family-medicine.md.
  • Commit your progress by running this command in the PowerShell terminal:
git add .
git commit -m "Add timeline, pricing, acceptance, change control, risks, governance, and signatures"

Now run the critical cross-reference check. Before you look at the answer, ask yourself: can you trace a single dollar from Section 9 back through Section 8 to Section 3 to Section 10?

  • Open your SOW file and trace this chain: pick any payment amount in Section 9.1, find the milestone it funds in Section 8.2, identify the deliverables that milestone requires, then check that those deliverables have acceptance criteria in Section 10.2.

For example: Phase 2 costs $19,500 (Section 9.1). Milestone M3 gates Phase 2's payment and requires D4, D5, D6, D7 to be deployed and operational (Section 8.2). D4 has acceptance criteria: "generates draft clinical notes for 2 pilot physicians over 5 consecutive business days with less than 20% physician edit rate" (Section 10.2). Every dollar traces to a measurable, verifiable outcome.

  • Verify by running this command:
git log --oneline

You should see five commits, with the most recent being your timeline, pricing, and governance commit.

Payment chain does not trace cleanly?

If any payment is tied to a calendar date rather than a deliverable acceptance, revise it now. The test: could a client withhold payment by arguing a date was missed even though the deliverable was completed? If yes, your gate is wrong.

Also check that the milestone percentages (20% + 25% + 35% + 20%) sum to 100% and that $7,800 + $9,750 + $13,650 + $7,800 = $39,000.

Help me verify my SOW payment chain is internally consistent.

✔️ Awesome, I've got everything!

Great. Your SOW now contains all 14 sections. Double check you have saved the file.

ⓧ I'd like to double check the full code

Your sow-greenfield-family-medicine.md should now contain all of these sections in order. Scroll through and confirm each is present:

  • Section 1: Executive Summary (placeholder).
  • Section 2: Business Objectives (from Step 2).
  • Section 3: Scope of Work with exclusions and deliverables table (from Step 3).
  • Section 4: Assumptions and Dependencies (from Step 3).
  • Section 5: Technical Requirements (from Step 4).
  • Section 6: Security and Compliance with data classification table (from Step 4).
  • Section 7: Roles and Responsibilities (from Step 3).
  • Section 8: Timeline and Milestones with payment gates table (this step).
  • Section 9: Pricing and Payment Terms with fee structure and pricing analysis (this step).
  • Section 10: Acceptance Criteria with deliverable-specific criteria table (this step).
  • Section 11: Change Control with triggers and minor adjustment carve-outs (this step).
  • Section 12: Risk Register with 8 risks (this step).
  • Section 13: Support and Transition (this step).
  • Section 14: Terms and Governance with IP and termination (this step).
  • Signatures block at the very end (this step).

Your SOW is now a complete, 14-section consulting deliverable. Every payment traces to a milestone, every milestone traces to deliverables, and every deliverable has testable acceptance criteria. Next up, you will write the executive summary that sells this SOW to a non-technical practice owner, plus a change order that proves you can handle scope evolution.

Secret mission

Executive Summary and Change Order

Write the executive summary that sells the SOW to a non-technical practice owner, plus a fully detailed change order for a realistic scope expansion request. Together, these two documents demonstrate the moments that define professional consulting: winning the work and protecting it.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally using VS Code, Git, and GitHub. There are no ongoing costs, no cloud resources, and no paid services to worry about.

Resources you used:

  • Local project folder (project-04-ai-scope-of-work on your Desktop).
  • GitHub repository (project-04-ai-scope-of-work).

Keep everything running

No action needed. Choose this if you want your portfolio piece to stay visible and accessible.

  • Your GitHub repository is your portfolio piece. Keep it public so hiring managers and clients can review your SOW.
  • Your local folder stays on your Desktop for future reference or iteration.
  • No costs are incurred by keeping these resources.

Pause - I'll come back to this later

Free up Desktop space while keeping your GitHub repository intact for later.

  • Your GitHub repository stays online with all your commits preserved. No action needed there.
  • Optionally move your local project-04-ai-scope-of-work folder off your Desktop into an archive folder to keep things tidy.
  • When you return, clone the repository from GitHub to restore everything.

Delete - I don't want to use this again

Remove all project resources from your machine and GitHub.

  • Delete the local project folder by opening PowerShell and running:
cd ~/Desktop
Remove-Item -Recurse -Force project-04-ai-scope-of-work
  • Delete the GitHub repository by opening your repository page in a browser.
  • Click Settings at the top of the repository page.
  • Scroll down to the Danger Zone section at the bottom.
  • Click Delete this repository and follow the confirmation prompts.

Nice Work!

Nice Work!

You just built a professional, executive-ready AI Statement of Work for a healthcare consulting engagement. This is a portfolio-ready deliverable you could hand to a practice owner and defend every line.

You've learned how to:

  • Translate raw discovery findings into a complete 14-section SOW with measurable business objectives, explicit exclusions that block scope creep, and milestone-based pricing that ties payment to deliverable acceptance rather than calendar dates.
  • Build HIPAA-aware security requirements with specific data classifications, vendor controls, and encryption standards that a third party could audit, while clearly distinguishing your technical consulting role from legal authority.
  • Design a change control process with defined triggers, approval mechanisms, and a risk register linked to specific SOW mechanisms, giving you a contractual path to handle scope evolution without eroding profitability.
  • Secret Mission: Wrote an executive summary that sells a complex engagement to a non-technical decision maker in under two minutes, plus a complete change order with itemized impact assessment proving you handle scope expansion professionally.

Ready to quiz yourself?