name: project-pause-protocol-runner description: > Executes the full Project Pause Protocol SOP — documenting current project status, generating a client-facing pause memo, freezing all open action items, and setting a re-engagement trigger. Run when a project needs to be paused or put on hold. metadata: author: "Kathryn Brown, Practice Builders" version: "1.0.0" date: "2026-04-28" sop: "Project Pause Protocol" category: "Client Communication" frequency: "Trigger-Based" estimated-time: "30 min" trigger: "When a project needs to be paused or put on hold"

Project Pause Protocol — Runner

You are executing the Project Pause Protocol SOP for an independent consultant. Projects get paused — client-side capacity, budget holds, internal reorganizations. How you manage the pause determines whether the engagement resumes cleanly or dies quietly. Without a documented pause protocol, scope drifts, context evaporates, and re-engagement requires rebuilding momentum you've already built once.

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

What you'll have when this is done: A sent pause memo with client acknowledgment, a frozen action item list, and a dated re-entry trigger in your calendar and pipeline tracker. The project can resume without a status reconstruction session.

Step 1: Collect All Inputs

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

Pause context:

• Pause reason: client-initiated vs. your recommendation
• Specific cause (budget hold, capacity constraint, internal reorg, missing dependency, other)
• Was this discussed verbally or is this the first formal communication?

Project status:

• Client name and primary contact name
• Project/engagement name
• Last milestone completed
• Next milestone that was pending
• Any outstanding deliverables or client-side inputs still due

Workstream details (for each active workstream):

• Workstream name
• Status: Completed / In Progress / Not Started
• What's been delivered or completed
• What was next in the queue
• Where artifacts live (shared drive, email, Notion, other)

Open action items (all sources — recaps, emails, notes, verbal commitments):

• For each item: description, owner (specific name), deadline (if any), status (open / in progress / blocked)
• Source of each item (which session, email, or conversation)

Re-engagement plan:

• Agreed restart date (specific) or trigger condition ("when X is resolved")
• Preferred check-in cadence during the pause (e.g., 30-day check-in)
• What the first action at restart should be (specific workstream and step)
• Escalation path if the pause extends beyond the agreed timeline

Communication details:

• Client's preferred communication channel for the pause memo
• Tone preference (formal / professional-warm / casual-professional)
• Any sensitivities to navigate in the framing

Step 2: Document Current Project Status

Before any communication, produce a clear status snapshot. This is your re-entry map.

• Last completed milestone: [From inputs]
• In-progress work: [From inputs]
• Open action items on either side: [Summary count — details come in Step 4]
• Outstanding deliverables or inputs still due: [From inputs]

Rule: Do this before drafting the pause memo. Your notes are the foundation for everything that follows.

Step 3: Generate the Pause Memo (Project Pause Communication — Condensed)

Using the pause reason, current status, and re-engagement timeline, produce the client-facing pause memo.

3a. Determine the Pause Framing

Select the appropriate frame based on the reason:

• Client-side constraint — Frame as a practical decision that respects their priorities. "Given [constraint], pausing gives your team the space to [what they need to do] so we can resume with full focus." Never frame it as their failure.
• Consultant-side constraint — Frame as responsible project management. "I want to give this engagement the attention it deserves, and [reason] means I can't do that right now. Here's my plan for resuming." Take ownership without over-sharing.
• Missing dependency — Frame as quality protection. "Continuing without [dependency] would mean rework later. Pausing now protects the work we've already completed."

One sentence explaining why. That's enough.

3b. Build the Status Table

For each active workstream:

This table serves double duty: it shows the client you've been organized, and it gives both of you a restart reference.

3c. Define the Restart Plan

• Proposed restart date or trigger: "[Specific date]" or "when [condition] is resolved"
• Check-in during pause: "I'll check in on [date]" or "let's reconnect the week of [date]"
• Restart first step: "We'll pick up with [specific workstream]"

Be specific. "Let's reconnect when things settle down" is a death sentence. "I'll reach out on May 15 to check in, and we'll plan to resume the week of June 1" is a restart plan.

3d. Draft the Email

Subject line: "[Project name] — Pause and Restart Plan"

Structure:

• Paragraph 1: The pause. State that you're recommending a pause and the reason. 1-2 sentences. No preamble.
• Paragraph 2: Current state. Summarize where things stand (reference the table below for detail). 2-3 sentences.
• Paragraph 3: Restart plan. State when and how you'll resume. Include the check-in commitment. 2-3 sentences.
• Paragraph 4: Reassurance. One sentence affirming the engagement and your commitment to picking back up. Professional, not sentimental.
• Attachment note: Reference the status table as included below the email.

Total email body: 120-200 words. The status table is separate.

3e. Pause Communication Quality Check

Run internally — never show to the user:

Identify the weakest section. Rewrite it. Verify the rewrite is present and improved before proceeding.

Step 4: Freeze the Action Item List (Action Item Tracker — Condensed)

Generate a frozen action item list — everything in motion at the time of pause, assigned to client or consultant. This prevents scope drift and "I thought you were doing that" conversations when the project resumes.

4a. Extract Every Open Item

From all provided inputs — recaps, emails, notes, verbal commitments — pull out every task, commitment, or deliverable that hasn't been marked complete.

For each item capture:

• Source: Where it came from (which recap, email, or note)
• Raw text: The exact language used
• Owner: Who is responsible (specific name — not "team" or "us")
• Deadline: When it's due (specific date or "none stated")
• Status: Open / In Progress / Blocked

Don't filter. If someone said "I'll send that over," that's an action item.

4b. Deduplicate

• Same task, different wording — keep the most specific version
• Same task, different deadlines — keep the most recent deadline, note the conflict
• Same task, different owners — flag for clarification (this is a risk)

4c. Build the Frozen Tracker

Group by owner (Consultant items first, then Client items, then Third Party items).

Consultant Items:

Client Items:

4d. Flags and Risks

Call out three categories:

• Overdue: Past deadline, no completion. Recommend: escalate, reassign, or close.
• Stale: Assigned 2+ sessions ago, no progress. Recommend: break down, reassign, or close.
• Unowned: Mentioned but never formally assigned. Recommend: assign or remove.

For each flagged item, include a specific recommended action.

4e. Action Item Quality Check

Run internally:

Identify the weakest section. Rewrite it before proceeding.

Step 5: Set Re-Engagement Triggers

• [ ] Calendar reminder set for agreed re-engagement date, or 30-day check-in if timeline is open
• [ ] Pause logged in pipeline tracker so it surfaces in pipeline review
• [ ] Written confirmation requested from client that they've received and reviewed the pause memo and action item list

Step 6: Assemble Final Output

Present one unified document containing:

A. Pause Memo

The complete email from Step 3 (subject line, email body, status table, restart plan).

Format:

**Subject:** [Project Name] — Pause and Restart Plan

Hi [Client first name],

[Paragraph 1: The pause — what and why. 1-2 sentences.]

[Paragraph 2: Current state summary. 2-3 sentences.]

[Paragraph 3: Restart plan — when, how, first step. 2-3 sentences.]

[Paragraph 4: Reassurance — 1 sentence.]

I've included a status summary below for reference.

[Warm close],
[Your name]

---

## Project Status at Pause

| Workstream | Status | Completed | Pending | Location |
|------------|--------|-----------|---------|----------|
| [Name] | [Status] | [What's done] | [What's next] | [Where] |

## Restart Plan

- **Proposed restart:** [Date or condition]
- **Check-in during pause:** [Date and method]
- **First action at restart:** [Specific workstream and step]

B. Frozen Action Item List

The complete tracker from Step 4 (grouped by owner, with flags and risks).

Format:

# Frozen Action Item List: [Client Name]
**Frozen:** [Date] | **Reason:** Project pause | **Total open items:** [Count]

## Active Items — Consultant

| # | Action | Deadline | Status | First Assigned |
|---|--------|----------|--------|---------------|
| 1 | [Verb-first task] | [Date] | [Status] | [Source] |

## Active Items — Client

| # | Action | Owner | Deadline | Status | First Assigned |
|---|--------|-------|----------|--------|---------------|
| 1 | [Verb-first task] | [Name] | [Date] | [Status] | [Source] |

## Flags

- **Overdue:** [Item] — due [date]. Do this: [specific action].
- **Stale:** [Item] — assigned [source], no progress. Do this: [specific action].
- **Unowned:** [Item] — mentioned in [source]. Do this: [specific action].

## Tracker Health

- Open items: [Count]
- Items with deadlines: [Count]/[Total]
- Overdue: [Count]
- Stale (2+ sessions): [Count]

C. Re-Engagement Checklist

D. SOPs to Trigger

• [ ] Client Session Cycle — for managing the re-entry cadence when the pause lifts
• [ ] Weekly Pipeline Review — ensure the paused project surfaces in pipeline reviews during the hold

Quality Check

Rules

1. Document before you communicate. Complete the project status snapshot before drafting the pause memo. Your notes are your re-entry map — writing the email first means you'll miss something.
2. Collect all inputs in one pass. Do not scatter prompts across multiple turns. Ask once, flag gaps, keep moving.
3. Never let a project pause without documentation. A verbal "let's pick this up later" rarely leads to an actual restart. A documented pause with a status table restarts far more often.
4. Always include a check-in date during the pause. Silence kills restarts. If you commit to reaching out on May 15, reach out on May 15 — even if nothing has changed.
5. Never blame the client for the pause, even if it's their fault. Frame it as a practical decision, not an accountability exercise.
6. Keep the email body under 200 words. The status table carries the detail.
7. Always state what the first restart action will be. The client should be able to picture exactly what happens when you resume.
8. Freeze the action item list completely. Items in-flight at the pause get forgotten otherwise. When the project resumes, you'll spend the first session reconstructing what should have been documented in 10 minutes.
9. Every action item needs a named owner. "We" and "the team" are not owners. Items without deadlines get flagged, not dropped.
10. Use verb-first language for every action item. "Send the proposal" not "Proposal needs to be sent."
11. Get written confirmation. The pause memo and action item list must be acknowledged by the client. Without confirmation, you don't know they've seen it.
12. Escape dollar signs as \$ for Notion compatibility.
13. Flag inferred details. If a status or deadline was inferred rather than stated, mark it [INFERRED — verify].

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.