Source: frameworks/kit-change-communication/04-change-communication-quality.md

Quality — Change Communication QC Checklists

Beat 1 Gate — Structural Planning

Run these checks after Beat 1 (project scaffolding). All must pass before the communication skeleton is considered complete.

Team Filter

[ ] Client has a team affected by at least one build (if no, this kit doesn't apply — stop here)
[ ] Affected team members identified by name from reference data
[ ] Each build mapped to the team members it will affect

Communication Sequence Skeleton

[ ] Skeleton sequence exists with at least: owner announcement → process owner walkthrough → first cycle → first win acknowledgment
[ ] Owner announcement is Step 1 with no prerequisite
[ ] Every other step has a prerequisite referencing an earlier step
[ ] Gate row present between owner announcement and all downstream steps
[ ] Build references match project plan numbering

Ownership Mapping

[ ] Gold = firm owner in all communication documents (decided and documented)
[ ] Stone = operations manager / process owner of the operational system
[ ] Mapping decision is the inverse of the SOP ownership (called out explicitly)

Project Plan Integration

[ ] Communication steps added to project plan as items
[ ] Owner announcement has a target date or milestone trigger
[ ] Communication sequence is referenced in the project plan or blueprint

Beat 2 — Pre-Flight (All Documents)

Run these checks on every document before delivering to client.

Brand Compliance

[ ] Correct theme (light/dark per client brand system)
[ ] Typography matches client brand (headings, body, code/data fonts)
[ ] No consultant branding in client-facing document body
[ ] Header: client brand name, document type, title, date
[ ] Footer: client brand primary, consultant name · Advisory OS · Month Year secondary
[ ] Status badge present with correct label

Ownership Color Mapping

[ ] Gold = process owner of THIS document (not the underlying operational process)
[ ] Copper/approver color = correct role per document context
[ ] Stone = support/execution roles within this document
[ ] Steel blue = consultant (if referenced)
[ ] Green = completed items only
[ ] Navy = structure/headers only (never used as an ownership color)
[ ] Verification: No person appears in two different colors within the same document
[ ] Verification: Legend matches CSS class definitions exactly
[ ] Verification: Every border color on cards/sections matches the owner of that content
[ ] Verification: If a person is gold in one document and stone in another, the reason is clear (different process, different ownership)

Content Language Rules

[ ] No "It's not X, it's Y" constructions anywhere
[ ] No "That's not a gift. That's homework" patterns
[ ] No negation-then-correction patterns (e.g., "Not a celebration. A factual acknowledgment.")
[ ] No clever parallel phrases
[ ] No fabricated experience claims
[ ] No fabricated quotes — every quote traceable to session transcript, email, or Slack evidence
[ ] Role titles match client conventions (check spelling, formal vs. casual reference)
[ ] Person names spelled correctly throughout
[ ] No consultant jargon (e.g., "constraint pattern" is internal methodology — use plain language in client-facing docs)

Change Communication Plan — Specific Checks

Sequence Logic

[ ] Step 1 has no prerequisite
[ ] Every other step has exactly one prerequisite referencing an earlier step or external condition
[ ] No circular dependencies
[ ] Gate row(s) present where one step must block downstream steps
[ ] Gate row blocks the correct steps (typically: owner announcement blocks everything downstream)
[ ] Build references match project plan numbering (Build 1, Build 2, etc.)
[ ] Build references describe the correct build content

Timing Accuracy

[ ] Month of the close cycle is correct. The close being deployed is the current cycle, not next month. If active close starts the first business day of March for February's books, the reference is "February close" not "March close."
[ ] Phase divider labels match the correct month ("During February Close" not "During March Close")
[ ] "By When" dates are realistic and match the project plan timeline
[ ] "First Friday after close" and similar timing references point to the right calendar date
[ ] Prerequisite text references the correct dates for existing sessions/meetings

First Win Protocol

[ ] Trigger is concrete and measurable (not "when things are going well")
[ ] Trigger maps to a real milestone in the project plan
[ ] Acknowledgment mechanism uses an existing communication channel (CEO memo, team meeting, etc.)
[ ] Example language sounds like the owner, not the consultant
[ ] "Why it matters" explanation connects to team perception, not management theory

What This Needs from You Section

[ ] Action items organized by timing (before/during/after cycle)
[ ] Each item has a "what" and a "why"
[ ] Border colors match the owner (gold for owner actions, navy for structural items, green for post-close)
[ ] No action item requires the owner to build something — these are communication and review actions only

Sponsor Activation Brief — Specific Checks

Team Announcement Framework

[ ] Three-part structure present (What's Changing, Who Owns It, What It Means for You)
[ ] Adapt note present and explicit ("Starting point — adapt to your voice")
[ ] Language blocks sound like the owner based on their session quotes
[ ] Optional context paragraph is genuinely optional (labeled as such, not woven into the core message)
[ ] "Who Owns It" section explicitly names the process owner's authority with the phrase "full authority" or equivalent

1:1 Conversation Scenarios

[ ] Each scenario was extracted from actual evidence (not generic templates)
[ ] Trigger phrases match what was actually said or closely paraphrased
[ ] Each scenario has: trigger box, acknowledge step, redirect step, specific language, avoid note
[ ] Avoid notes are specific and actionable (not generic "be sensitive")
[ ] Language in redirect step reframes without dismissing the team member's concern
[ ] No scenario undermines the process owner's authority
[ ] No scenario promises the team member can bypass the process owner

Coaching Block

[ ] Framed as building capability, not catching mistakes or evaluating performance
[ ] Transcript request is positioned as optional (the owner can decline)
[ ] Explains what the consultant will do with the transcripts (feedback on communication patterns)
[ ] No language suggesting surveillance or assessment

Change Network

[ ] Every person named is already in the project plan stakeholder map
[ ] No invented roles or people
[ ] Each person has: name/title, what they own, why the team needs to understand their function
[ ] Role descriptions don't overlap (each person has distinct scope)
[ ] No one in the change network is assigned communication tasks that belong to the owner

Team Communication Playbook — Specific Checks

Structure

[ ] Navigation tabs present for each communication type
[ ] Each tab shows: timing label, name, time estimate (duration + prep time)
[ ] Prep time is shorter than conversation duration for every section
[ ] Each section is self-contained (usable without reading other sections)
[ ] JavaScript tab switching works correctly
[ ] Print mode shows all sections expanded
[ ] Print mode shows all scenario panels visible (not hidden behind tabs)

Team Meeting Section

[ ] Numbered talking points with time estimates that sum to total duration
[ ] Direction text explains what the owner is doing at each point
[ ] Language blocks labeled as "Starting point — adapt to your voice"
[ ] Close/final talking point includes instruction to stop (resist the urge to keep softening)
[ ] Outcome box describes what the team should know after the meeting

1:1 Concerns Section

[ ] Scenario tabs match the scenarios in the Sponsor Activation Brief
[ ] Each scenario has: trigger box, steps, language blocks, avoid note
[ ] Scenario structure matches across all scenarios (acknowledge → redirect → be specific)
[ ] Tab interface works correctly (clicking shows correct panel, hides others)
[ ] Outcome box addresses what happens if resistance continues after the conversation

CEO Memo Section

[ ] 2-3 trigger templates covering different outcomes
[ ] At least one template covers "something went wrong but the system caught it" (the resilience win)
[ ] Fill-in-the-blank placeholders are clearly marked and visually distinct
[ ] Draft language is 1-2 sentences (not a paragraph — brevity is the point)
[ ] "Why this matters" explanation connects acknowledgment to team adoption

Weekly Check-In Section

[ ] Three structured questions (escalation check, team response check, support check)
[ ] Total time estimate is 5 minutes or less
[ ] Outcome box explicitly names the old pattern this replaces
[ ] Questions are ordered from most urgent (anything need attention?) to most supportive (what do you need from me?)

Cross-Document Verification

After all three documents pass individual QC:

[ ] Ownership color for each person is consistent across all three documents (or the difference is intentional and documented — e.g., owner is gold in communication docs, copper in the SOP)
[ ] Build references use the same numbering across all three documents
[ ] Person names are spelled the same way across all three documents
[ ] The communication sequence in the Plan matches the sponsor moments in the Brief
[ ] The 1:1 scenarios in the Brief match the scenario tabs in the Playbook
[ ] The First Win Protocol in the Plan matches the CEO Memo triggers in the Playbook
[ ] Month references are correct across all three documents (audit every instance)
[ ] Footer format is identical across all three documents

Scoring

Each section scored: Pass | Fail | Warning (technically correct but could be improved)

Blocking failures (must fix before delivery):

Any ownership color mapping error
Any month/timing inaccuracy
Any content rule violation (AI writing patterns)
Any fabricated quote
Any person name spelled incorrectly
Gate mechanism missing or blocking the wrong steps

Warnings (fix if time permits, note for next iteration):

Prep time exceeds conversation duration in any playbook section
Language block doesn't closely match owner's speech patterns
Avoid notes are generic rather than specific
Optional elements not clearly labeled as optional