# Communication Plan

# Communication Plan: {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Communication Objectives

<!-- GUIDANCE: Define what this communication plan is designed to achieve.
Good communication reduces escalations, builds trust, and keeps everyone aligned.
Be specific about what "good communication" looks like on this project. -->

This communication plan ensures that all stakeholders on **{{PROJECT_NAME}}** receive accurate, timely, and relevant information throughout the project lifecycle. Specific objectives:

1. **Transparency** — All stakeholders have visibility into project status, risks, and decisions at the appropriate level of detail
2. **Alignment** — Requirements, priorities, and decisions are communicated before work begins, not after
3. **Accountability** — Issues, blockers, and escalations are surfaced quickly and resolved through defined channels
4. **Trust** — Consistent, professional communication builds client confidence and internal cohesion
5. **Documentation** — Key decisions, changes, and approvals are recorded and retrievable

---

## 2. Stakeholder Communication Needs Matrix

<!-- GUIDANCE: Different stakeholders need different information at different frequencies.
Over-communicating to senior stakeholders creates noise; under-communicating creates surprises.
Map each stakeholder's specific information needs and preferred channel. -->

| Stakeholder | Role | Information Needs | Preferred Channel | Frequency | Detail Level | Owner |
|-------------|------|-------------------|------------------|-----------|-------------|-------|
| {{NAME}} | Client Sponsor | Budget, milestone status, risks | Email + Video | Weekly | Executive summary | PM |
| {{NAME}} | Client PO | Feature status, backlog, demos | Video + Chat | Per-sprint | Detailed | PO |
| {{NAME}} | End Users | Launch date, training schedule | Email | Monthly + pre-launch | Simple | PM |
| Alem (CEO) | ALAI CEO | Budget, strategic issues | Direct | As needed / monthly | Executive | John |
| John (AI Director) | AI Director | Full project status, risks, decisions | Daily digest | Daily | Detailed | PM |
| {{NAME}} | PM | Blockers, task progress | Chat | Daily | Detailed | Team |
| {{NAME}} | Tech Lead | Technical decisions, architecture | Chat | Daily | Technical | Team |
| {{NAME}} | QA | Test status, bug counts | Chat | Daily | Detailed | QA |

---

## 3. Communication Channels & Tools

<!-- GUIDANCE: Define which tool is used for which purpose. Mixing channels (e.g., decisions in chat
instead of decision records) creates confusion. Establish norms and enforce them. -->

| Channel | Tool | Purpose | Who Has Access | Response SLA |
|---------|------|---------|---------------|-------------|
| Daily standup | Mattermost / written | Daily progress, blockers | Dev team | Same day |
| Sprint communication | Project chat channel | Sprint-specific updates | Full team | 4 hours |
| Video calls | {{TOOL, e.g., Teams/Zoom/Meet}} | Meetings requiring discussion | Invited parties | N/A (scheduled) |
| Status reports | Email | Formal stakeholder updates | Stakeholders | N/A (push) |
| Decision records | Project wiki / CLAUDE | Architectural & project decisions | Team + future ref | N/A (log) |
| Urgent/P1 issues | Phone + Mattermost | Critical blockers, incidents | All stakeholders | 15 minutes |
| Document sharing | {{TOOL, e.g., Google Drive/Confluence}} | Documents, specs, deliverables | Authorized team | N/A |
| Issue tracking | Mission Control / GitHub Issues | Bugs, tasks, change requests | Team | 24 hours |
| External email | Email | Formal client communication | PM, John, Alem | 24 hours |
| Signing | Documenso (sign.alai.no) | Contracts, NDAs, approvals | Parties to sign | Per agreement |

---

## 4. Meeting Schedule

<!-- GUIDANCE: Document every recurring meeting. Unnecessary meetings are expensive;
missing meetings create gaps. Every meeting needs a purpose, agenda, and owner. -->

### 4.1 Regular Meetings

| Meeting | Purpose | Frequency | Day / Time | Duration | Required Attendees | Facilitator | Output |
|---------|---------|-----------|------------|----------|-------------------|-------------|--------|
| Daily Standup | Progress, blockers, coordination | Daily (weekdays) | {{DAY}} {{TIME}} | 15 min | Dev team + PM | Scrum Master | Written standup log |
| Sprint Planning | Backlog grooming, sprint goal, task assignment | Every 2 weeks (Monday) | {{TIME}} | 2 hours | Team + PO | Scrum Master | Sprint backlog |
| Sprint Review / Demo | Demo completed features to client | Every 2 weeks (Friday) | {{TIME}} | 1 hour | Team + Client | PO | Sprint demo recording |
| Sprint Retrospective | Team process improvement | Every 2 weeks (Friday) | {{TIME}} | 1 hour | Dev team (no client) | Scrum Master | Retro action items |
| Client Sync | Relationship, quick updates, concerns | Weekly | {{DAY}} {{TIME}} | 30 min | PM + Client PO | PM | Meeting notes |
| Steering Committee | Strategic decisions, budget, major risks | Monthly | {{DAY}} {{TIME}} | 1 hour | PM + John + Client Sponsor | PM | Decision record |
| Risk Review | Risk register update | Weekly (sprint planning) | Embedded | 15 min | PM + Tech Lead | PM | Updated risk register |

### 4.2 Event-Triggered Meetings

| Trigger | Meeting Type | Called By | Who | Target Timing |
|---------|-------------|-----------|-----|---------------|
| P1 incident | Incident response call | PM or Tech Lead | All hands | Within 1 hour |
| New risk Score ≥ 15 | Risk escalation | PM | PM + John + Sponsor | Within 24 hours |
| Scope change request received | Change review | PM | PM + TL + PO | Within 3 business days |
| Milestone missed | Recovery planning | PM | PM + TL + John | Within 24 hours |
| Go-live decision point | Go/No-Go review | PM | PM + TL + QA + John | 5 days before planned launch |

---

## 5. Reporting Cadence

<!-- GUIDANCE: Reports are the paper trail of project health. Define what each report contains,
who writes it, and who receives it. Templates for key reports are embedded below. -->

| Report | Frequency | Prepared By | Distributed To | Delivery Method | Deadline |
|--------|-----------|-------------|---------------|-----------------|----------|
| Daily Standup Log | Daily | PM / SM | John + internal team | Mattermost | EOD each day |
| Sprint Report | Per sprint | PM | Client + John | Email | Sprint end + 1 day |
| Weekly Status Report | Weekly | PM | Client Sponsor + John | Email | Every {{WEEKDAY}} by {{TIME}} |
| Monthly Risk Report | Monthly | PM | John + Alem | Email | 1st of each month |
| Monthly Budget Report | Monthly | PM | John + Alem | Email | 1st of each month |
| Milestone Report | Per milestone | PM | All stakeholders | Email | Day of milestone completion |
| Post-Launch Report | Once | PM | John + Client + Alem | Email | 30 days post-launch |

### 5.1 Weekly Status Report Template

<!-- GUIDANCE: Paste this template into your email each week. Keep it under 1 page. -->

```
SUBJECT: [{{PROJECT_NAME}}] Weekly Status — Week of {{DATE}}

STATUS: 🟢 On Track | 🟡 At Risk | 🔴 Delayed

## This Week
- {{COMPLETED_ITEM_1}}
- {{COMPLETED_ITEM_2}}

## Next Week
- {{PLANNED_ITEM_1}}
- {{PLANNED_ITEM_2}}

## Risks & Issues
| # | Issue/Risk | Status | Action Required From Client |
|---|------------|--------|----------------------------|
| 1 | {{ISSUE}} | {{STATUS}} | {{CLIENT_ACTION}} |

## Milestones
| Milestone | Target | Status |
|-----------|--------|--------|
| {{MILESTONE}} | {{DATE}} | ✅ Done / ⏳ In Progress / ⚠️ At Risk |

## Decisions Needed
- [ ] {{DECISION_NEEDED_BY_DATE}}

## Budget
- Spend to date: {{NOK}} / {{TOTAL_NOK}} ({{PERCENT}}%)
```

---

## 6. Escalation Paths & Response SLAs

<!-- GUIDANCE: Document exactly who to contact when and how fast they must respond.
Ambiguity in escalation paths leads to issues sitting unresolved. -->

| Level | Trigger | Escalate To | Channel | Response SLA | Resolution SLA |
|-------|---------|-------------|---------|-------------|----------------|
| L1 | Blocker within team (any) | Tech Lead | Chat | 2 hours | 4 hours |
| L2 | Blocker affecting sprint goal | PM | Chat + call if needed | 1 hour | Same day |
| L3 | Client-impacting issue | PM + John | Chat + email | 1 hour | 4 hours |
| L4 | Milestone risk (>3 days slip) | John + Client PM | Email + video | 4 hours | 2 business days |
| L5 | Budget overrun risk | John → Alem | Direct | 2 hours | 24 hours |
| L6 | Contract/scope dispute | John + Alem | Direct + email | 4 hours | 3 business days |
| P1 | Production incident | PM + Tech Lead + John + Client | Phone | 15 minutes | Per incident severity |

---

## 7. Documentation Standards

<!-- GUIDANCE: Consistent naming and storage prevents the "where is that document?" problem.
These standards apply to all project artifacts. -->

### 7.1 File Naming Convention

```
[PROJECT]-[DOCUMENT_TYPE]-[DATE]-[VERSION].[ext]
Example: ACME-sprint-report-2026-02-14-v1.0.pdf
Example: ACME-meeting-notes-2026-02-14.md
```

### 7.2 Document Storage Locations

| Document Type | Location |
|--------------|----------|
| Project charter, brief, RACI | `~/projects/{{PROJECT}}/docs/governance/` |
| Requirements, user stories, BRD | `~/projects/{{PROJECT}}/docs/requirements/` |
| Design files, mockups | `~/projects/{{PROJECT}}/docs/design/` |
| Meeting notes | `~/projects/{{PROJECT}}/comms/meetings/` |
| Standups | `~/projects/{{PROJECT}}/comms/standups/` |
| Decision records | `~/projects/{{PROJECT}}/comms/decisions/` |
| Sprint reports | `~/projects/{{PROJECT}}/comms/reports/` |
| Client-facing documents | `~/projects/{{PROJECT}}/comms/client/` |

### 7.3 Version Control

- All documents use semantic versioning: MAJOR.MINOR (e.g., 1.0, 1.1, 2.0)
- MAJOR version = significant structural change or approval milestone
- MINOR version = content updates, corrections, additions
- Every version tracked in the Document History table at the top of each file

---

## 8. External Communication Protocols

<!-- GUIDANCE: Communications to parties outside the project team (client contacts, press,
partners, regulators) require additional care. Define who is authorized and how. -->

| Communication Type | Authorized Speakers | Approval Required | Notes |
|-------------------|--------------------|--------------------|-------|
| Client progress updates | PM, John | None (within scope) | Must be factual, professional |
| Client escalations / issues | PM → John | John approval | Never promise resolution timelines without TL input |
| Press / public statements | Alem | Alem only | No project details without explicit approval |
| Partner communication | John | John | Document all commitments |
| Legal / contract matters | Alem + John | Alem | No binding commitments without Alem sign-off |
| Social media | Alem | Alem | Check brand guidelines first |
| Third-party vendor comms | Tech Lead / DevOps | PM awareness | Cc PM on all vendor emails |

---

## 9. Crisis Communication Plan

<!-- GUIDANCE: Define how communication changes when things go seriously wrong.
A crisis is any situation that threatens project delivery, client relationship, or ALAI reputation. -->

### 9.1 Crisis Triggers

- Production data breach or security incident
- > 2-week unplanned project delay
- Client relationship breakdown
- Team member critical unavailability (e.g., extended illness)
- Budget overrun > 25%
- Legal dispute

### 9.2 Crisis Communication Protocol

1. **Identify** — Team member identifies crisis; notifies PM immediately
2. **Contain** — PM + Tech Lead assess scope and containment options (max 1 hour)
3. **Escalate** — PM notifies John within 1 hour; John notifies Alem if L4+
4. **Communicate** — PM prepares crisis communication draft; John approves before sending
5. **Update** — Stakeholders receive updates every 4 hours until resolved
6. **Resolve** — Crisis declared over by John; post-mortem conducted within 48 hours
7. **Learn** — `/learning-opportunity` — crisis becomes system fix

### 9.3 Crisis Communication Template

```
SUBJECT: [URGENT] {{PROJECT_NAME}} — {{CRISIS_SUMMARY}}

Dear {{STAKEHOLDER}},

We are writing to inform you of an issue affecting {{PROJECT_NAME}}.

SITUATION: {{WHAT_HAPPENED}}
IMPACT: {{WHAT_IS_AFFECTED}}
IMMEDIATE ACTIONS TAKEN: {{WHAT_WE_HAVE_DONE}}
NEXT STEPS: {{WHAT_WE_WILL_DO}}
EXPECTED RESOLUTION: {{TIMELINE}}

We will provide updates every {{FREQUENCY}} until this is resolved.

Contact: {{PM_NAME}} — {{PM_EMAIL}} — {{PM_PHONE}}

{{NAME}}
{{TITLE}}
```

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Project Manager | | | |
| AI Director (John) | | | |
| Client Sponsor | | | |