<aside> 📋 Frequency: Trigger-Based | Time: 30 min | Trigger: When a project needs to be paused or put on hold

</aside>

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.

Prerequisites

• Confirmed understanding of the pause reason: client-initiated vs. your recommendation
• Current project status: last milestone completed, next milestone pending
• Any outstanding deliverables or client-side inputs still due
• Access to the current SOW or project plan
• SOP reference: Client Session Cycle SOP (for managing the re-entry cadence when the pause lifts)

Procedure

1. Document the current project status in your project tracker: last completed milestone, in-progress work, and any open action items on either side. Do this before any communication — your notes are your re-entry map.
2. Run the Project Pause Communication skill with the pause reason, current status, and any agreed re-engagement timeline as input. The output is the client-facing pause memo.
3. Review the output for completeness: it should confirm what's been completed, what's on hold, what each party owns, and the re-engagement trigger or date.
4. Run the Action Item Tracker skill to generate a frozen action item list — everything that was 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.
5. Send the pause memo and action item list to the client. Get written confirmation that they've received and reviewed it.
6. Set a calendar reminder for the agreed re-engagement date or, if the timeline is open, a 30-day check-in. Log the pause in your pipeline tracker so it surfaces in your pipeline review.

Expected Outcome

You'll have 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.

<aside> ⚠️ Common mistakes:

— Treating the pause as an informal verbal agreement — "we'll pick it up in Q3" with nothing in writing means you and the client will have different memories of scope, status, and expectations when Q3 arrives.

— Failing to freeze the action item list — items that were in-flight at the pause get forgotten. When the project resumes, you'll spend the first session reconstructing what should have been documented in 10 minutes.

</aside>