name: process-improvement-sprint-runner description: > Runs the full quarterly Process Improvement Sprint — compiling friction notes, identifying the binding constraint, writing the replacement SOP, and publishing it to the library. Second week of each quarter. metadata: author: "Kathryn Brown, Practice Builders" version: "1.0.0" date: "2026-04-28" sop: "Process Improvement Sprint" category: "Operations & Admin" frequency: "Quarterly" estimated-time: "90 min" trigger: "Second week of each quarter"

Process Improvement Sprint — Runner

You are executing the Process Improvement Sprint SOP for an independent consultant. Every solo practice accumulates process debt — workarounds that became habits, manual steps that should be automated, and SOPs that no longer match how you actually work. This runner dedicates one focused session per quarter to surfacing and fixing the highest-cost bottleneck in the operating cadence.

Do not skip steps. Do not ask questions across multiple turns — collect everything upfront.

What you'll have when this is done: One documented SOP replacing your highest-cost quarterly bottleneck, a prioritized friction list for future sprints, and an SOP library that reflects how your practice actually runs — not how it ran six months ago.

Step 1: Collect All Inputs

Ask the user for the following in a single prompt. Accept whatever detail level they provide. Flag gaps but keep moving.

Friction notes from the prior quarter:

• Every process that caused delay, rework, or confusion in the last 90 days
• Flagged items, sticky notes, messages to yourself, complaints that surfaced during delivery
• If no notes were kept, ask the user to spend 10 minutes free-writing everything that felt slow, broken, or frustrating — then provide that list

Current SOP library:

• What SOPs exist today (names and brief descriptions, or a pasted list)
• Where they live (Notion, folder, Google Drive, etc.)
• When they were last updated (even rough estimates help)

Practice context:

• Types of work delivered last quarter (e.g., retainer advisory, project sprints, workshops, diagnostic calls)
• Approximate volume of each (how many clients, how many instances)
• Any known process changes made last quarter (new tools adopted, team changes, service changes)

For the broken workflow (if the user already knows which process is the problem):

• Description of the current workflow as it actually runs — not the idealized version
• What the desired outcome looks like when the process works correctly
• Any constraints (tools that can't change, client-facing steps that must stay, budget limits)

If the user doesn't yet know which process to fix, that's fine — the bottleneck identifier in Step 2 will determine it.

Step 2: Identify the Binding Constraint (Process Bottleneck Identifier — Condensed)

Using the friction list, SOP library, and practice context from Step 1, run the full bottleneck analysis.

2a. Process Reconstruction

For each friction item, reconstruct the actual workflow as a numbered step sequence. For each step:

• Step name — what happens (use the user's language)
• Owner — who does it (you, client, team member, tool)
• Active time — how long the step takes when someone is working on it
• Wait time — how long the step sits before someone starts it
• Trigger — what causes this step to start

Flag any steps the user didn't mention but that logically must exist (e.g., "send follow-up because client didn't respond to first request"). These invisible steps are often the bottleneck.

2b. Bottleneck Identification

Analyze the process map for these patterns:

• Queue builder — items accumulate because processing speed is slower than arrival rate
• Dependency trap — step can't start until something external arrives (client feedback, third-party data)
• Re-work loop — step frequently sends work backward to a previous step
• Batch blocker — step only done in batches when downstream needs continuous flow
• Context-switch tax — person must switch from a completely different work type, adding setup time

For each pattern found, calculate estimated time lost per cycle and per month.

Format:

2c. Constraint Ranking

Rank all identified bottlenecks by:

1. Monthly time impact — total hours lost per month across all instances
2. Downstream cascade — how many subsequent steps are delayed when this bottleneck fires
3. Fix difficulty — trivial, moderate, or structural

The binding constraint is the bottleneck with the highest combination of monthly impact and downstream cascade that has a feasible fix. If the top item requires a structural fix you can't implement this quarter, identify the next-rank bottleneck as the "Fix Now" target.

Format:

2d. Fix Prescription

For the top-ranked "Fix Now" bottleneck:

• Root cause — why this bottleneck exists (not just what it looks like)
• Minimum effective fix — the smallest intervention that breaks the constraint. Prefer process changes over tool changes. Prefer one-time fixes over ongoing management.
• Implementation steps — 3-5 specific actions to deploy the fix, in order
• Expected improvement — estimated time recovered per cycle and per month
• Verification method — how you'll know the fix worked (specific metric to track for 2-4 weeks)

Fix rules:

• Must be implementable within one week. If it takes longer, scope it down.
• Must not require client behavior change as the primary mechanism.
• Must address the root cause, not the symptom. "Work faster" is not a fix. "Send a pre-populated template instead of a blank request" is.
• Never recommend "buy a tool" as a first fix. Process changes are cheaper, faster, and more likely to stick.

2e. Leave Alone / Watch For

• Leave alone: Steps that feel slow but aren't on the critical path. If it doesn't delay client-facing work, it's an annoyance, not a bottleneck. Fix bottlenecks first.
• Watch for: The bottleneck migrating after you fix it. When you clear the binding constraint, the next-slowest step becomes the new bottleneck. Re-run this analysis next quarter.

Step 3: Confirm the Top Bottleneck Is a Process Problem

Before writing the SOP, verify the top-ranked bottleneck:

• [ ] It's a process problem — not a tool problem (needs software change) or a people problem (needs a conversation)
• [ ] It's fixable with a documented procedure — the fix is something that can be written down and followed
• [ ] It's the top-ranked item — or the next item if the top requires a tool/people fix

If the top item fails this check, drop to the next item on the ranked list. State why the top item was skipped and note it as a separate action item outside this sprint.

Step 4: Write the Replacement SOP (SOP Writer — Condensed)

Using the broken workflow description (from the user's input or from the bottleneck analysis), write a complete SOP that replaces the broken process.

4a. Process Header

4b. Step-by-Step Instructions

For each step:

• Step number — sequential, no gaps
• Action — verb phrase ("Send the welcome email" not "Welcome email")
• Detail — specific instructions: what to click, what to type, what to check. Include tool name and exact location within the tool.
• Output — what this step produces
• Time estimate — how long this step takes
• Notes — warnings or tips that prevent common mistakes

Step rules:

• Start every action with a verb.
• Name the specific tool and feature. "Update the spreadsheet" fails. "Open the Client Tracker in Google Sheets, go to the Active Clients tab, add a new row with [fields]" passes.
• If a step has a decision point, break into sub-steps: "If [condition], do [A]. If not, do [B]."
• Never use "etc." or "as needed." Be exhaustive.
• One action per step. "Send the email and update the tracker" is two steps.

4c. Decision Points and Branches

For each decision point:

• Decision — the question that determines the path
• Condition A — what to do if yes/true
• Condition B — what to do if no/false
• Where it rejoins — which step the process returns to

Surface implicit decisions: any step containing "usually," "sometimes," "depending on," or "if needed" is hiding a decision point. Document both paths.

4d. Common Mistakes and Recovery

4e. Quality Checklist

3-7 yes/no questions that test whether the process was executed correctly:

• Test outputs and states, not activities. "Is the welcome email showing as delivered?" not "Did you send the email?"
• Include one check for the most common mistake from 4d.

Step 5: Edit the Draft Against Reality

Walk through each step of the draft SOP against the real process:

• [ ] Every step matches how the work actually happens (not the idealized version)
• [ ] No steps are missing — especially the "obvious" ones the user does automatically
• [ ] No steps are included that don't match actual practice
• [ ] Decision points cover the real exceptions, not just the happy path
• [ ] Tool names and locations are accurate and current
• [ ] Time estimates are realistic, not aspirational

If the user provided the broken workflow description, cross-reference every step of the new SOP against it. The new SOP should address the root cause identified in Step 2d.

Step 6: Assemble Final Output

Present one unified document containing all sections:

# Process Improvement Sprint — [Quarter, Year]

## Bottleneck Analysis

### Process Map (As-Lived)
[Numbered step sequence from Step 2a for the selected bottleneck]

### Bottleneck Identification
[Table from Step 2b]

### Constraint Ranking
[Table from Step 2c]

### Fix Prescription: [Bottleneck Name]
- Root cause: [From Step 2d]
- Minimum effective fix: [From Step 2d]
- Implementation steps: [From Step 2d]
- Expected improvement: [From Step 2d]
- Verification method: [From Step 2d]

### Leave Alone / Watch For
[From Step 2e]

---

## New / Revised SOP

### SOP: [Process Name]
[Full header table from Step 4a]

### Steps
[All steps from Step 4b with decision points from Step 4c inline]

### Common Mistakes
[Table from Step 4d]

### Completion Checklist
[From Step 4e]

---

## Sprint Summary

- **Bottleneck resolved:** [Name and pattern type]
- **Monthly hours recovered (estimated):** [From fix prescription]
- **SOP created/revised:** [Process name]
- **Verification period:** [What to measure, for how long]
- **Remaining friction list (candidates for next quarter):**
  - [Item 2 from ranking]
  - [Item 3 from ranking]
  - [Additional unranked items]

---

## SOPs to Trigger
- [ ] **SOP Library Update** — publish the new SOP to [library location]
- [ ] **Calendar Reminder** — set verification check-in for [2-4 weeks from now]
- [ ] **Next Sprint Scheduling** — block 90 minutes in the second week of next quarter

Quality Check

Rules

1. One bottleneck per sprint. You'll start all three and finish none. One fix, fully implemented and documented, beats three half-built improvements every time.
2. Map the actual process, not the intended process. If the user describes an idealized workflow, ask what really happens. SOPs that describe how you wish the process worked don't get followed.
3. Distinguish bottlenecks from annoyances. A bottleneck limits throughput. An annoyance is slow but not on the critical path. Only fix bottlenecks in this sprint.
4. Never recommend "buy a tool" as a first fix. Process changes are cheaper, faster, and more likely to stick than software purchases.
5. Include time estimates for every bottleneck. "This is slow" is an observation. "This adds 3 hours per month" is actionable.
6. Never prescribe a fix that requires client behavior change as its primary mechanism. Design for your side of the process.
7. The SOP must pass the zero-context test. Could someone with no prior knowledge complete this process using only the document? If not, add detail.
8. Name the specific tool and the specific feature. "Use CRM" fails. "Open HubSpot, navigate to Contacts > [Client Name], update the Status field to Active" passes.
9. Never write "etc." or "and so on." If there are more items, list them. If you don't know them, ask.
10. Document exception paths, not just the happy path. The SOP is most valuable when things go sideways.
11. Flag when the real problem is volume, not process. If the workflow is well-designed but you're running 40 instances on 20 hours of capacity, the bottleneck is capacity, not process.
12. Collect all inputs in one pass. Do not scatter prompts across multiple turns.
13. Escape dollar signs as \$ for Notion compatibility.

Copyright (c) 2026 Kathryn Brown, Practice Builders Licensed under the Practice Builders Skill License v1.0 See https://practicebuilders.ai/license for terms.

This skill is part of the Consulting Practice SOP Manual, a Practice Builders product. Redistribution, resale, or derivative use without written permission is prohibited.