# Project Charter

# Project Charter: {{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. Vision & Mission

<!-- GUIDANCE: Write a compelling 2-3 sentence vision describing the end state this project creates.
The mission statement explains HOW the project achieves that vision. Be specific to this project. -->

**Vision:** {{VISION_STATEMENT}}
> _What does success look like 12 months after launch? What has changed for the business or users?_

**Mission:** {{MISSION_STATEMENT}}
> _How does this project deliver the vision? What approach, principles, or methods define delivery?_

**Strategic Alignment:**
> _How does this project align with ALAI's or the client's broader business strategy? Reference the relevant OKR or business goal._

---

## 2. Scope

<!-- GUIDANCE: Be precise. Scope misunderstandings are the #1 source of project disputes.
In-scope items are contracted deliverables. Out-of-scope protects both parties. -->

### 2.1 In Scope — Deliverables

| # | Deliverable | Description | Acceptance Criteria Summary |
|---|-------------|-------------|-----------------------------|
| D-01 | {{DELIVERABLE}} | {{DESCRIPTION}} | {{ACCEPTANCE_CRITERIA}} |
| D-02 | | | |
| D-03 | | | |
| D-04 | | | |
| D-05 | | | |

### 2.2 Out of Scope

<!-- GUIDANCE: List explicitly what is NOT included. This prevents scope creep. Common exclusions:
data migration from legacy systems, ongoing hosting/maintenance post-launch, third-party licensing,
content creation, translations, training delivery, future feature phases. -->

- {{OUT_OF_SCOPE_ITEM_1}}
- {{OUT_OF_SCOPE_ITEM_2}}
- {{OUT_OF_SCOPE_ITEM_3}}

### 2.3 Assumptions

<!-- GUIDANCE: List conditions assumed to be true for this project to succeed as scoped.
If an assumption proves false, it may trigger a change request. -->

| # | Assumption | Risk if False | Owner to Validate |
|---|------------|---------------|-------------------|
| A-01 | {{ASSUMPTION}} | {{RISK}} | {{OWNER}} |
| A-02 | | | |

### 2.4 Constraints

<!-- GUIDANCE: Non-negotiable limitations. Technology choices, regulatory requirements,
fixed deadlines, budget ceilings, team size, platform mandates. -->

| # | Constraint | Category | Impact |
|---|------------|----------|--------|
| C-01 | {{CONSTRAINT}} | Technical / Legal / Budget / Time | {{IMPACT}} |
| C-02 | | | |

---

## 3. Stakeholder Register

<!-- GUIDANCE: Every person/organization with an interest in project outcomes.
Interest = what they care about. Influence = their power to affect the project.
Engagement Strategy = how you keep them informed and supportive. -->

| ID | Name | Organization | Role | Interest | Influence | Engagement Strategy | Contact |
|----|------|--------------|------|----------|-----------|---------------------|---------|
| S-01 | {{NAME}} | {{ORG}} | Sponsor | {{INTEREST}} | High | Steering committee monthly | {{EMAIL}} |
| S-02 | | | Product Owner | | High | Sprint reviews, daily | |
| S-03 | | | End User Rep | | Medium | UAT sessions | |
| S-04 | | | Technical Lead | | High | Daily standup | |
| S-05 | | | Finance/Legal | | Medium | Monthly reports | |

**Key Decision Makers:**
- Final scope decisions: {{DECISION_MAKER}}
- Technical architecture approval: {{TECH_APPROVER}}
- Budget approval: {{BUDGET_APPROVER}}
- Contract/legal: {{LEGAL_APPROVER}}

---

## 4. Budget Summary

<!-- GUIDANCE: Provide total budget with breakdown. Include contingency reserve (typically 10-20%).
Payment milestones should align with delivery milestones, not calendar dates. -->

| Line Item | Amount (NOK) | % of Total | Notes |
|-----------|-------------|------------|-------|
| Development | {{AMOUNT}} | | |
| Design | {{AMOUNT}} | | |
| Infrastructure / Hosting | {{AMOUNT}} | | |
| Third-party licenses / APIs | {{AMOUNT}} | | |
| Testing / QA | {{AMOUNT}} | | |
| Project Management | {{AMOUNT}} | | |
| **Subtotal** | **{{SUBTOTAL}}** | **100%** | |
| Contingency Reserve (15%) | {{CONTINGENCY}} | | For approved change requests |
| **Total Budget** | **{{TOTAL}}** | | |

**Payment Schedule:**

| Milestone | % | Amount (NOK) | Due Date |
|-----------|---|-------------|----------|
| Contract signing | 50% | {{AMOUNT}} | {{DATE}} |
| MVP delivery | 25% | {{AMOUNT}} | {{DATE}} |
| Final delivery + UAT sign-off | 25% | {{AMOUNT}} | {{DATE}} |

---

## 5. Timeline & Milestones

<!-- GUIDANCE: List major milestones with gate criteria. A milestone is not complete until
its gate condition is verified. Use the Gantt diagram placeholder below for visual representation. -->

| # | Milestone | Target Date | Gate Condition | Owner |
|---|-----------|-------------|----------------|-------|
| M-01 | Project Kick-off | {{DATE}} | Charter approved, team onboarded | PM |
| M-02 | Requirements Complete | {{DATE}} | BRD/FRS approved by PO + client | BA |
| M-03 | Design Approved | {{DATE}} | All mockups signed off | Designer |
| M-04 | MVP / Alpha Release | {{DATE}} | Core features functional, deployed to staging | Tech Lead |
| M-05 | Beta Release | {{DATE}} | All features complete, regression tests pass | QA |
| M-06 | UAT Complete | {{DATE}} | UAT sign-off document signed | PM |
| M-07 | Production Launch | {{DATE}} | Go-live checklist passed, monitoring active | DevOps |
| M-08 | Post-launch Handover | {{DATE}} | Documentation delivered, support transition done | PM |

**Gantt Diagram (placeholder):**

```mermaid
gantt
    title {{PROJECT_NAME}} — Project Timeline
    dateFormat  YYYY-MM-DD
    section Planning
    Project Kick-off        :done, m1, {{START_DATE}}, 3d
    Requirements Gathering  :active, req, after m1, 14d
    section Design
    UI/UX Design            :des, after req, 14d
    Design Review           :milestone, after des, 1d
    section Development
    Sprint 1                :s1, after des, 14d
    Sprint 2                :s2, after s1, 14d
    Sprint 3                :s3, after s2, 14d
    section Testing & Launch
    UAT                     :uat, after s3, 7d
    Production Launch       :milestone, after uat, 1d
```

---

## 6. Success Criteria & KPIs

<!-- GUIDANCE: Success criteria must be measurable and verifiable. For each criterion,
specify HOW it will be measured and WHEN it will be evaluated. Avoid vague statements. -->

| # | Success Criterion | KPI / Metric | Target | Measurement Method | Evaluation Point |
|---|-------------------|-------------|--------|--------------------|------------------|
| SC-01 | {{CRITERION}} | {{KPI}} | {{TARGET}} | {{METHOD}} | {{WHEN}} |
| SC-02 | System performance | Page load time | < 2 seconds (p95) | Lighthouse / monitoring | Launch + 30 days |
| SC-03 | User adoption | Active users | {{TARGET}} in 90 days | Analytics dashboard | 90 days post-launch |
| SC-04 | Quality | Bug rate | < 5 critical bugs post-launch | Issue tracker | 30 days post-launch |
| SC-05 | Client satisfaction | NPS score | ≥ 8/10 | Post-launch survey | 60 days post-launch |

---

## 7. Dependencies

<!-- GUIDANCE: External dependencies that could block or delay the project.
Each dependency should have an owner responsible for resolving it and a target resolution date. -->

| # | Dependency | Type | Impact if Delayed | Owner | Target Date | Status |
|---|-----------|------|-------------------|-------|-------------|--------|
| DEP-01 | {{DEPENDENCY}} | Internal / External / Client | {{IMPACT}} | {{OWNER}} | {{DATE}} | Pending |
| DEP-02 | | | | | | |

---

## 8. Governance Model

<!-- GUIDANCE: Define who makes what decisions and how disagreements are resolved.
Clear governance prevents escalation spirals and delays. -->

### 8.1 Decision-Making Authority

| Decision Category | Authority | Must Consult | Must Inform |
|-------------------|-----------|--------------|-------------|
| Scope changes | PO + John | Tech Lead, PM | Client, Alem |
| Architecture decisions | Tech Lead | Developer team | PM, John |
| Budget changes > 10% | Alem | John, PM | Client |
| Release go/no-go | Tech Lead + PM | QA, DevOps | John, Client |
| Team changes | John | PM | Alem |
| Contract amendments | Alem | John | Client |

### 8.2 Change Control Process Summary

<!-- GUIDANCE: Define the process for handling scope changes during the project. -->

1. **Request:** Any stakeholder submits a Change Request (CR) using the `change-request.md` template
2. **Impact Analysis:** PM + Tech Lead assess scope, timeline, budget, and risk impact within 3 business days
3. **Decision:** PO + John approve/reject within 2 business days of impact analysis
4. **Budget changes > 10%:** Require Alem approval
5. **Implementation:** Approved CRs are logged, prioritized in backlog, and scheduled
6. **Communication:** All stakeholders notified of approved/rejected CRs within 24 hours

### 8.3 Escalation Hierarchy

```
L1: Team Member → Tech Lead (response: 4 hours)
L2: Tech Lead → PM (response: 8 hours)
L3: PM → John (response: 4 hours)
L4: John → Alem (response: 24 hours — strategic/financial only)
```

---

## 9. Team & Roles

<!-- GUIDANCE: Assign specific named individuals or agent IDs to each role.
Refer to the separate RACI matrix for detailed responsibility assignments. -->

| Role | Agent / Person | Responsibilities | Availability |
|------|---------------|-----------------|--------------|
| Project Sponsor | {{NAME}} | Strategic direction, final approvals, budget | As needed |
| AI Director | John | Delivery accountability, agent coordination | Full-time |
| Project Manager | {{AGENT}} | Coordination, reporting, risk, stakeholder comms | Full-time |
| Business Analyst | {{AGENT}} | Requirements, acceptance criteria, documentation | Full-time |
| Tech Lead | {{AGENT}} | Architecture, code review, technical decisions | Full-time |
| Developer(s) | {{AGENT}} | Feature implementation | Full-time |
| Designer | {{AGENT}} | UI/UX, design system, assets | Part-time |
| QA Engineer | {{AGENT}} | Test planning, execution, sign-off | Full-time |
| DevOps | {{AGENT}} | Infrastructure, CI/CD, deployment | Part-time |

---

## 10. Risk Summary

<!-- GUIDANCE: High-level risk overview. Full risk register maintained in risk-register.md.
Only list top 5 risks here with their mitigation summary. -->

| # | Risk | Probability | Impact | Mitigation |
|---|------|------------|--------|------------|
| R-01 | {{RISK}} | H/M/L | H/M/L | {{MITIGATION}} |
| R-02 | | | | |
| R-03 | | | | |
| R-04 | | | | |
| R-05 | | | | |

> Full risk register: `[risk-register.md](risk-register.md)`

---

## Approval

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