Project Governance

Project charter, brief, risk register, RACI, communication plan

Project Charter: Drop — Fintech Payment App

Project Charter: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments Version: 1.1 Date: 2026-02-08 (updated 2026-02-23) Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-08 John Initial draft
1.0 2026-02-13 John Updated after Phase 0.5 security sprint
1.1 2026-02-23 John Aligned with ROADMAP.md and current pipeline state

1. Vision & Mission

Vision: Drop becomes the default payment tool for all residents in Norway who need to send money abroad or pay at local businesses — capturing the remittance + QR payments market that no single app currently serves together.

Mission: Build a PSD2 pass-through fintech app (never holding customer money) that offers remittance at 0.5% and QR merchant payments at 1%, powered by Open Banking — cheaper and simpler than every existing alternative.

Strategic Alignment: Drop is ALAI Holding AS's flagship product, demonstrating AI-native product development from zero to market. It aligns with ALAI's mission to "build digital" and generates recurring revenue through transaction fees. Innovasjon Norge Oppstartstilskudd (150K NOK) provides initial runway.

2. Scope

2.1 In Scope — Deliverables

# Deliverable Description Acceptance Criteria Summary
D-01 Web App (Next.js) Full-featured payment app with 10 screens All pages functional, deployed to staging at drop-staging.fly.dev
D-02 Remittance Flow Send money to 30+ countries at 0.5% fee via PISP User can initiate transfer; 6 corridors working (RS, BA, PK, TR, PL, EUR)
D-03 QR Payment Flow Pay merchants by scanning QR code at 1% fee Merchant QR generated; customer scan + payment flow functional
D-04 Open Banking Integration AISP (read balance) + PISP (initiate payments) via BaaS partner Real bank connection via BankID + selected BaaS provider
D-05 KYC + BankID Onboarding Identity verification, age 18+, Norwegian residency Users verified via BankID; KYC status tracked per user
D-06 Landing Page Marketing site at getdrop.no with waitlist Live on Vercel; waitlist collecting emails
D-07 CI/CD + Monitoring GitHub Actions pipeline + Fly.io deployment All tests green in CI; staging auto-deploys on merge

2.2 Out of Scope

2.3 Assumptions

# Assumption Risk if False Owner to Validate
A-01 BaaS partner (Swan or SpareBank1) confirms by Phase 2 Phase 2 blocked indefinitely Alem
A-02 Finanstilsynet PISP/AISP registration process takes ~3 months Launch delayed Alem + Legal advisor
A-03 Users have Norwegian BankID and +47 phone Onboarding conversion low Alem (user research)
A-04 Open Banking APIs from BaaS provider are stable Integration rework required John
A-05 Innovasjon Norge grant (150K NOK) is approved Cash flow gap before revenue Alem

2.4 Constraints

# Constraint Category Impact
C-01 Drop NEVER holds customer money (PSD2 pass-through model) Legal / Regulatory Architecture must use AISP/PISP only
C-02 Minimum user age: 18 (BankID DOB validation) Legal Onboarding must validate DOB
C-03 NEVER use word "banking" without licence disclaimer Legal All copy must be reviewed
C-04 Norwegian BankID required for onboarding Technical Locks market to Norway initially
C-05 Budget: ~250K NOK total (150K Innovasjon Norge + bootstrap) Financial AI-first development to minimise costs
C-06 PCI-DSS: NEVER store or expose full card numbers/CVV Security Cards feature requires tokenisation partner

3. Stakeholder Register

ID Name Organization Role Interest Influence Engagement Strategy Contact
S-01 Alem Bašić ALAI Holding AS CEO / Sponsor Strategic success, revenue, brand High Direct sessions, all major decisions alem@alai.no
S-02 John ALAI Holding AS AI Director / Product Owner Technical delivery, product quality High Daily async, all sprint reviews —
S-03 SpareBank1 contact SpareBank1 Banking Partner Candidate Partnership revenue, market expansion High Quarterly meetings, pitch materials Via Alem
S-04 Swan (BaaS) Swan.io BaaS Provider Candidate API adoption, merchant fees Medium Technical integration discussions Via John
S-05 Finanstilsynet Norwegian FSA Regulator PSD2 compliance, consumer protection High Formal registration process Via legal advisor
S-06 Early users (waitlist) — End Users Cheap remittance, easy QR payments Low Waitlist comms, beta invitations hei@getdrop.no
S-07 Local merchants Oslo area Merchant Users Lower fees than Vipps, easy setup Medium Door-to-door onboarding Alem

Key Decision Makers:

4. Budget Summary

Line Item Amount (NOK) % of Total Notes
Development (AI-first) 10,000 4% Claude Code + tooling costs
Open Banking integration (PSD2) 15,000 6% BaaS setup + API costs
Legal + compliance setup 50,000 20% Finanstilsynet registration, legal review
Marketing launch 100,000 40% Social media, local merchant onboarding
QR stickers + merchant kits 20,000 8% Physical materials
Buffer / contingency 55,000 22% Unexpected costs
Total Budget 250,000 100%

Payment Schedule: Internal project — Innovasjon Norge Oppstartstilskudd (~150K NOK) + bootstrapped by ALAI.

Milestone Amount (NOK) Source
Phase 0.5 completion (security hardening) 0 (AI cost only) ALAI bootstrap
Phase 1 (demo app) ~25,000 Innovasjon Norge
Phase 2 (bank integration) ~125,000 Innovasjon Norge
Phase 3 (launch) ~100,000 Revenue + grant

5. Timeline & Milestones

# Milestone Target Date Gate Condition Owner
M-01 Phase 0 — Foundation 2026-02-08 Landing page live, brand done, pipeline test passed John
M-02 Phase 0.5 — MVP Hardening 2026-02-20 Security audit passed, 217 tests green, staging live John
M-03 Phase 1 — Demo App 2026-03-15 Full 10-screen app functional, investor-ready demo John
M-04 BaaS Partner Decision 2026-03-01 SpareBank1 answer or Swan signed Alem
M-05 Phase 2 — Banking Integration 2026-04-30 Real BankID, AISP, PISP working with 10 beta users John
M-06 Finanstilsynet Registration 2026-05-15 PISP/AISP licence submitted Alem + Legal
M-07 Phase 3 — Production Launch 2026-06-15 App Store + Play Store live, 200 merchants onboarded John + Alem
M-08 Post-launch Review 2026-07-15 1,000 users, monitoring active, external pentest done John

Gantt Diagram:

gantt
    title Drop — Project Timeline
    dateFormat  YYYY-MM-DD
    section Foundation
    Phase 0 Foundation       :done, p0, 2026-02-08, 7d
    Phase 0.5 Hardening      :done, p05, after p0, 14d
    section Demo
    Phase 1 Demo App         :active, p1, 2026-02-20, 28d
    section Integration
    BaaS Partner Decision    :milestone, baas, 2026-03-01, 1d
    Phase 2 Banking          :p2, after p1, 56d
    Finanstilsynet Filing    :milestone, reg, 2026-05-15, 1d
    section Launch
    Phase 3 Production       :p3, 2026-05-15, 30d
    Go Live                  :milestone, live, 2026-06-15, 1d

6. Success Criteria & KPIs

# Success Criterion KPI / Metric Target Measurement Method Evaluation Point
SC-01 Revenue generation Monthly Recurring Revenue 130,000 NOK/month Transaction logs Month 12 post-launch
SC-02 User acquisition Registered users 3,000 App analytics Month 12 post-launch
SC-03 Merchant adoption Onboarded merchants 200 Merchant dashboard Month 12 post-launch
SC-04 System performance API response time p95 < 500ms Monitoring Launch + 30 days
SC-05 Security posture Security score ≥ 80/100 Security audit Pre-launch
SC-06 Transaction reliability Payment success rate ≥ 99% Transaction logs Ongoing post-launch
SC-07 Fee competitiveness Remittance fee vs Wise 0.5% vs 0.7-1.5% Competitor monitoring Ongoing

7. Dependencies

# Dependency Type Impact if Delayed Owner Target Date Status
DEP-01 BaaS provider (Swan or SpareBank1) External Phase 2+ blocked Alem 2026-03-01 SpareBank1 pitched; awaiting
DEP-02 Finanstilsynet PISP/AISP registration External / Regulatory Real payments blocked Alem + Legal 2026-05-15 Not started
DEP-03 BankID integration via BaaS External SCA/onboarding blocked John After BaaS selected Pending BaaS
DEP-04 KYC provider (Sumsub or partner KYC) External AML compliance blocked John After BaaS selected Mock in place
DEP-05 Phase 0.5 security hardening Internal Phase 1 blocked John 2026-02-20 In progress

8. Governance Model

8.1 Decision-Making Authority

Decision Category Authority Must Consult Must Inform
Scope changes Alem (CEO) John All stakeholders
Architecture decisions John (AI Director) Tech Lead agents Alem
Budget changes > 10% Alem John —
Release go/no-go John QA agents Alem
Partner/legal decisions Alem John + Legal advisor —
Team / agent changes John — Alem

8.2 Change Control Process Summary

  1. Request: Any stakeholder raises change request via change-request.md template
  2. Impact Analysis: John assesses scope, timeline, budget within 3 business days
  3. Decision: Alem approves/rejects within 2 business days
  4. Budget changes > 10%: Require Alem explicit approval via session
  5. Implementation: Approved changes logged in comms/decisions/, scheduled in roadmap
  6. Communication: All stakeholders notified within 24 hours

8.3 Escalation Hierarchy

L1: Agent → John (response: 4 hours)
L2: John → Alem (response: 24 hours — strategic/financial only)
L3: Alem → External advisor (legal/regulatory only)

9. Team & Roles

Role Agent / Person Responsibilities Availability
Project Sponsor / CEO Alem Bašić Strategic direction, partnerships, budget approvals, regulatory Part-time (decisions + partnerships)
AI Director John (Claude Opus) Delivery accountability, architecture, agent coordination Full-time
Developer / Builder Builder (Claude Sonnet) Feature implementation, API routes, frontend pages Per-task
QA / Validator Validator (Claude Sonnet) Testing, validation, code review Per-task
Security Security agent (Claude) Threat modelling, audit, compliance Per-sprint
Legal Legal agent (Claude) Regulatory review, document drafting As needed
Finance Finance agent (Claude) Budget analysis, projections As needed

10. Risk Summary

# Risk Probability Impact Mitigation
R-01 Banking partner / BaaS not secured in time High High Multi-provider approach; Swan as backup to SpareBank1
R-02 Finanstilsynet registration delayed Medium High Start process early; operate under bank partner licence initially
R-03 Security breach before production hardening Low Critical Security audit completed; 8 critical fixes tracked; no real money in MVP
R-04 Vipps launches remittance product Medium High Already ahead in market; community trust and lower fees are moat
R-05 Slow merchant adoption Medium Medium Door-to-door in local communities; 0% fee for first 3 months

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

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-08 Approved (AI)
Reviewer John (AI Director) 2026-02-23 Reviewed (AI)
AI Director (John) John 2026-02-08 Approved
Project Sponsor Alem Bašić 2026-02-08 Approved
CEO Alem Bašić 2026-02-08 Approved

Project Brief: Drop — Fintech Payment App

Project Brief: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments for Scandinavia Version: 1.0 Date: 2026-02-08 Author: John (AI Director) + product agent Status: Approved Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-08 product agent Initial discovery brief
1.0 2026-02-08 John Finalised after 2-round agent analysis

1. Executive Summary

Drop is a fintech payment app for all residents in Norway/Scandinavia, offering remittance at 0.5% fee (vs Western Union 5-10%, Wise 0.7-1.5%) and QR merchant payments at 1% (vs Vipps 1.75-2.75%). Built on PSD2 Open Banking — Drop never holds customer money; payments are initiated directly from users' bank accounts via PISP. The Norwegian remittance market is worth 5.7 billion NOK annually, and no existing app combines both remittance and QR payments. ALAI Holding AS (org.nr 932 516 136), led by CEO Alem Bašić, is building Drop as an AI-native product with total startup costs of ~250K NOK, targeting break-even within 7-9 months of launch. Decision: GO.

2. Business Context & Market Opportunity

2.1 Business Context

Norway has ~1,000,000 immigrants (SSB data) who collectively send 5.7 billion NOK abroad annually. They are systematically overcharged by Western Union (5-10% fees), and underserved by Wise and Revolut (generic, not community-focused). At the same time, local immigrant-owned businesses are paying Vipps 1.75-2.75% per transaction — a significant cost for low-margin businesses (kebab shops, kiosks, bakeries, barbers). Alem Bašić identified this dual pain from personal experience as a community member.

2.2 Market Opportunity

Dimension Current State Opportunity
Market Size 5.7B NOK annual remittance from Norway Capture 1% = 57M NOK ARR potential
Target Segment ~1M immigrants + ~195K SMEs in Norway Broad appeal beyond diaspora
Growth Rate Remittance market growing 8% YoY Early mover advantage
Key Trend PSD2 Open Banking enabling pass-through payments No legacy infrastructure cost

2.3 Strategic Fit

This project directly supports:

3. Problem Statement

3.1 Core Problem

Residents of Norway with international money transfer needs and local payment needs are served by fragmented, expensive, or poorly designed tools. No single app combines affordable international remittance (< 1% fee) with QR-based local merchant payments (< 1.5% fee) in the Norwegian market.

3.2 Pain Points

# Pain Point Affected Stakeholder Measurable Impact
P-01 International transfers cost 5-10% (Western Union) Immigrants sending money home ~285M NOK/year overcharged on 5.7B NOK market at 5% avg
P-02 Vipps merchant fees (1.75-2.75%) eat into thin margins Local small businesses Kebab shop at 50K NOK/month pays 875-1,375 NOK in fees
P-03 Existing remittance apps (Wise, Revolut) not designed for community trust Immigrant communities Low adoption due to UX and cultural mismatch
P-04 No combined remittance + QR app exists in Norway All residents Users need 2+ apps; no flywheel effect

3.3 Current State Gaps

Current Process/System: Users use Western Union / MoneyGram for remittance and Vipps for local payments. Two separate apps, two fee structures, zero integration.

Key Gaps:

Cost of Inaction: ALAI has no recurring product revenue. The window to enter before a major player copies the remittance + QR combo is estimated at 12-18 months.

4. Proposed Solution Overview

4.1 Solution Description

Drop is a mobile-first web app (PWA/React Native path) built on PSD2 Open Banking. Users link their Norwegian bank account via BankID. Remittances are initiated as PISP bank transfers directly from the user's account (no top-up, no wallet). QR payments work the same way — merchant generates a QR code, customer scans and confirms, payment goes directly from bank account to merchant settlement. Drop never holds funds. Revenue: 0.5% remittance fee + 1% merchant fee.

4.2 Key Capabilities

# Capability Addresses Pain Point Priority
CAP-01 Remittance to 30+ countries at 0.5% P-01 Must Have
CAP-02 QR merchant payments at 1% P-02 Must Have
CAP-03 BankID onboarding + KYC P-03 Must Have
CAP-04 Open Banking AISP (balance view) P-04 Must Have
CAP-05 Transaction history and notifications P-04 Should Have
CAP-06 Merchant dashboard (analytics + QR generation) P-02 Should Have
CAP-07 Loyalty / rewards programme P-03 Could Have

4.3 Solution Architecture (High Level)

graph LR
    A[User / Merchant] --> B[Drop Web App - Next.js]
    B --> C[Drop API - Next.js API Routes]
    C --> D[PostgreSQL Database]
    C --> E[BaaS Provider - Swan or SpareBank1]
    E --> F[Norwegian Banks via PSD2]
    E --> G[BankID - SCA]
    E --> H[KYC Provider - Sumsub]
    C --> I[Remittance Corridors - 30+ countries]

4.4 Platforms & Channels

5. Key Benefits & ROI Projection

5.1 Quantified Benefits

Benefit Category Description Estimated Annual Value
Revenue (remittance fees) 3,000 users × 2 tx/month × 1,000 NOK × 0.5% 360,000 NOK/year (Year 1)
Revenue (merchant fees) 200 merchants × 50,000 NOK/month × 1% 1,200,000 NOK/year (Year 1)
Cost reduction vs agencies AI-first dev: 10K vs typical 500K NOK agency cost 490,000 NOK saved
Total Annual Benefit (Year 1) ~1,560,000 NOK

5.2 ROI Calculation

Metric Value
Total Investment (Year 1) 250,000 NOK
Total Annual Benefit (Year 1) ~1,560,000 NOK
Payback Period 7-9 months
3-Year ROI ~1,800%
Net Present Value (3yr) ~10,000,000 NOK

Assumptions: 200 merchants at 50K NOK/month average transaction volume; 3,000 consumers sending 1,000 NOK twice per month; 0.5% remittance fee; 1% merchant fee. Conservative projections per business case v2.1.

5.3 Qualitative Benefits

6. High-Level Requirements

# Requirement Type Priority Notes
HLR-01 Users must verify identity via Norwegian BankID Functional Must Have Age ≥ 18, Norwegian residency
HLR-02 Remittance to 30+ countries via PISP Functional Must Have 6 corridors in MVP: RS, BA, PK, TR, PL, EUR
HLR-03 QR merchant payments via PISP Functional Must Have Merchant generates QR; user scans + pays
HLR-04 Drop NEVER holds customer money Legal Must Have PSD2 pass-through only
HLR-05 GDPR compliance for Norwegian users Non-Functional Must Have Data minimisation, consent, right to deletion
HLR-06 NEVER use word "banking" without licence disclaimer Legal Must Have Marketing and UI copy constraint
HLR-07 99.9% uptime SLA for payment flows Non-Functional Should Have Financial reliability requirement
HLR-08 Transaction history with filters Functional Should Have User-facing transaction log

7. Competitive Landscape

Alternative Type Strengths Weaknesses Why Drop Wins
Western Union / MoneyGram Direct (remittance) Brand recognition, physical presence 5-10% fees, outdated UX 10-20x cheaper, mobile-native
Wise Direct (remittance) Low fees (0.7-1.5%), trusted brand No QR payments, generic/not local 0.5% vs 0.7-1.5%; QR combo unique
Vipps Direct (QR payments) Massive Norwegian market share No remittance, 1.75-2.75% merchant fee Drop does both; 50% cheaper for merchants
Revolut Indirect Feature-rich, international Complex, not community-focused, no QR Simpler UX, community trust, QR payments

Our Unique Value Proposition: Drop is the only app in Norway combining cheap remittance (0.5%) AND QR merchant payments (1%) in a single, BankID-native, community-trusted platform. No wallet. No top-up. Money stays in your bank.

8. Resource Requirements

8.1 Team

Role Effort Source
CEO / Sponsor 20% time (decisions, partnerships) Alem Bašić (ALAI)
AI Director / Product Owner Full-time John (ALAI internal AI)
Builder agents Per-task (Claude Sonnet) ALAI internal AI
Validator agents Per-task (Claude Sonnet) ALAI internal AI
Legal advisor As needed External (TBD)

8.2 Budget Summary

Category Estimated Cost (NOK)
Development (AI-first) 10,000
Open Banking / BaaS integration 15,000
Legal + compliance 50,000
Marketing launch 100,000
QR stickers + merchant kits 20,000
Contingency (22%) 55,000
Total 250,000

8.3 Timeline

Phase Duration Start
Phase 0.5 — Security Hardening 2 weeks 2026-02-08
Phase 1 — Demo App 4 weeks 2026-02-20
Phase 2 — Banking Integration 8 weeks 2026-03-20
Phase 3 — Launch 6 weeks 2026-05-15
Total Duration ~20 weeks 2026-02-08

9. Go / No-Go Decision Criteria

9.1 Go Criteria (ALL must be met)

9.2 No-Go Triggers (ANY is sufficient to stop)

9.3 Decision

Dimension Decision Decision Maker Date
Proceed with planning GO Alem Bašić 2026-02-08
Budget approved Yes Alem Bašić 2026-02-08
Resource allocation approved Yes Alem Bašić 2026-02-08

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-08 Approved (AI)
Reviewer John (AI Director) 2026-02-08 Reviewed
AI Director (John) John 2026-02-08 Approved
Project Sponsor Alem Bašić 2026-02-08 Approved
CEO Alem Bašić 2026-02-08 Approved

Risk Register: Drop — Fintech Payment App

Risk Register: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments Version: 1.1 Date: 2026-02-23 Author: John (AI Director) Status: Active Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-08 legal agent + finance agent Initial 2-round risk identification
1.0 2026-02-11 John Added technical risks from security audit
1.1 2026-02-23 John Closed resolved risks; updated statuses

1. Risk Identification Methodology

Identification Methods Used:

Initial Risk Assessment Date: 2026-02-08 Next Scheduled Review: 2026-03-01 (sprint planning) Risk Owner: John (AI Director)

2. Risk Categories

Category Description Common Examples
Technical Technology failures, integration issues, performance, security JWT secrets, SQLite limits, API race conditions
Resource Team availability, skill gaps, single points of failure Alem sole decision-maker, AI cost overruns
External Third-party dependencies, regulatory changes, market shifts BaaS partner, Finanstilsynet, Vipps competition
Financial Budget overruns, payment delays, cost estimates Grant approval delay, marketing burn
Regulatory Compliance failures, licence requirements, penalties PSD2 licence, AML, GDPR, PCI-DSS
Quality Defect rate, technical debt, process failures Security vulnerabilities, untested integrations

3. Risk Probability & Impact Scale

3.1 Probability Scale

Level Score Definition
Very Low 1 < 10% chance
Low 2 10–30% chance
Medium 3 30–50% chance
High 4 50–70% chance
Very High 5 > 70% chance

3.2 Impact Scale

Level Score Schedule Impact Financial Impact
Negligible 1 < 1 day < 1% budget
Minor 2 1–3 days 1–5% budget
Moderate 3 3–7 days 5–10% budget
Major 4 1–2 weeks 10–20% budget
Critical 5 > 2 weeks Project failure

3.3 Risk Matrix

Score Risk Level Response Required Escalation
1–4 LOW Monitor monthly PM awareness
5–9 MEDIUM Active mitigation plan John awareness
10–14 HIGH Immediate action + weekly review John escalation
15–25 CRITICAL Emergency response John + Alem

4. Risk Appetite Statement

Overall Risk Appetite: LOW (fintech — money movement requires high safety standards)

Risk Category Appetite Rationale
Technical (security) Very Low Financial app — zero tolerance for data breaches
Regulatory Very Low GDPR, PSD2, AML violations have criminal penalties
Financial Low Fixed budget; overruns require Alem approval
External (BaaS) Medium Modular architecture allows provider swap
Timeline Medium Some schedule flexibility acceptable
Competition High Market risk accepted; innovation is our moat

5. Active Risk Register

ID Risk Description Category Prob (1-5) Impact (1-5) Score Response Strategy Owner Status Date Identified
R-001 BaaS partner (Swan or SpareBank1) not confirmed — blocks Phase 2 Open Banking integration External 4 5 20 Mitigate Alem Mitigating — SpareBank1 pitched; Swan backup 2026-02-08
R-002 Finanstilsynet PISP/AISP registration delayed beyond planned timeline Regulatory 4 5 20 Mitigate Alem + Legal Open — not started 2026-02-08
R-003 Security breach before production hardening complete Technical 2 5 10 Mitigate John Mitigating — audit done; 8 critical fixes tracked 2026-02-11
R-004 Vipps launches competing remittance feature External 3 4 12 Accept Alem Monitoring 2026-02-08
R-005 Slow merchant adoption — QR revenue below projection External 3 3 9 Mitigate Alem Open — door-to-door strategy planned 2026-02-08
R-006 Hardcoded JWT_SECRET fallback active in production Technical 2 5 10 Mitigate John Mitigating — fix tracked in Phase 0.5 2026-02-11
R-007 CVV/card data exposed via GET API endpoint (PCI-DSS violation) Regulatory 2 5 10 Mitigate John Mitigating — last_four only; fix in Phase 0.5 2026-02-11
R-008 SQLite single-writer bottleneck at 200+ concurrent users Technical 2 3 6 Accept John Accepted for MVP; PostgreSQL migration planned 2026-02-13
R-009 Alem is sole human decision-maker — decision bottleneck Resource 3 3 9 Mitigate Alem Mitigating — decisions logged in comms/decisions/ 2026-02-08
R-010 KYC mock in production — AML compliance not active Regulatory 2 5 10 Mitigate John Open — Sumsub production required before real money 2026-02-13
R-011 No real BankID — DOB proxy insufficient for SCA Technical / Regulatory 2 4 8 Mitigate John Open — Phase 1 is demo only; BankID in Phase 2 2026-02-13
R-012 In-memory rate limiter resets on process restart — brute force risk Technical 2 4 8 Mitigate John Mitigating — DB-backed rate limits in Phase 0.5 2026-02-11
R-013 No CSRF protection on state-changing API endpoints Technical 2 4 8 Mitigate John Mitigating — CSRF middleware in Phase 0.5 2026-02-11
R-014 Cash flow gap if Innovasjon Norge grant delayed Financial 3 3 9 Mitigate Alem Monitoring — AI costs keep burn < 10K/month 2026-02-08
R-015 Race condition on concurrent remittance transactions (double-spend) Technical 2 5 10 Mitigate John Mitigating — per-user transaction lock implementation 2026-02-11

6. Risk Response Strategies

Risk ID Strategy Response Actions Contingency Plan
R-001 Mitigate 1. SpareBank1 pitch submitted; 2. Swan evaluated as backup; 3. Modular BaaS interface in architecture If neither works: explore Wio Bank, Finom, Treezor
R-002 Mitigate 1. Engage external legal advisor for Finanstilsynet process; 2. Apply early; 3. Operate under bank partner licence initially If delayed: launch in limited beta under partner licence
R-003 Mitigate 1. Security audit complete; 2. Phase 0.5 sprint fixes 8 critical issues; 3. No real money in MVP If breach occurs: incident response plan in security/incident-response.md
R-004 Accept Monitor Vipps announcements monthly; accelerate community adoption Emphasise 0.5% vs Vipps fees; focus on trust advantage
R-005 Mitigate 1. Door-to-door onboarding; 2. 0% fee for first 3 months; 3. 200-merchant target Month 12 Adjust fee structure; focus on high-volume corridors
R-006 Mitigate 1. JWT_SECRET required env var — fail fast; 2. Secrets via Vaultwarden Rotate secrets immediately; force re-auth
R-007 Mitigate 1. Remove CVV from GET response; 2. Store only last_four + token_ref; 3. Tokenisation via card partner Suspend cards feature until fixed
R-010 Mitigate 1. Sumsub integration contract; 2. Mock clearly gated by feature flag; 3. No real money until KYC live Suspend onboarding until KYC active
R-015 Mitigate 1. Per-user transaction lock (in-process); 2. DB-level constraint as backup; 3. PostgreSQL advisory locks in Phase 2 Suspend concurrent transactions; queue-based processing

7. Risk Heat Map

quadrantChart
    title Drop Risk Heat Map — 2026-02-23
    x-axis Low Impact --> High Impact
    y-axis Low Probability --> High Probability
    quadrant-1 "CRITICAL — Immediate Action"
    quadrant-2 "HIGH — Active Management"
    quadrant-3 "LOW — Monitor"
    quadrant-4 "MEDIUM — Watch"
    R-001 (BaaS partner): [1.0, 0.8]
    R-002 (Finanstilsynet): [1.0, 0.8]
    R-004 (Vipps): [0.8, 0.6]
    R-003 (Security): [1.0, 0.4]
    R-006 (JWT): [1.0, 0.4]
    R-007 (CVV): [1.0, 0.4]
    R-015 (Race condition): [1.0, 0.4]
    R-009 (Alem bottleneck): [0.6, 0.6]
    R-014 (Cash flow): [0.6, 0.6]
    R-008 (SQLite): [0.6, 0.4]

8. Escalation Thresholds

Threshold Action Responsible Timeframe
Any new risk Score ≥ 15 Escalate to Alem + John John Within 4 hours
Any existing risk score increases by ≥ 5 Escalate to John John Within 24 hours
> 3 risks at Score ≥ 10 simultaneously Emergency risk review John + Alem Within 48 hours
Risk triggers contingency plan Notify all stakeholders John Immediately
Risk causes milestone slip > 3 days Formal change request John Within 24 hours

9. Review Schedule

Frequency Activity Participants Output
Weekly (Sprint Planning) Review all active risks, update scores John Updated register
Sprint Retrospective New risks identified; closed risks archived John New risks logged
Monthly Full register review + heat map John, Alem Risk report
Milestone Risk review before go/no-go John, Alem Go/no-go input

Review Log

Date Reviewer Risks Reviewed New Added Closed Key Changes
2026-02-08 legal + finance agents — 6 0 Initial identification
2026-02-11 John (security audit) 6 10 0 Added R-006 through R-015
2026-02-23 John 15 0 5 Closed R-C01 to R-C05; updated statuses

10. Closed Risks Archive

ID Risk Description Resolution Type Resolution Notes Date Closed
R-C01 Wallet/balance model requires e-money licence Avoided Pivoted to PSD2 pass-through model (ADR-003) 2026-02-12
R-C02 FontelePay tightly coupled to Drop — regulatory risk Avoided Separated to own module (ADR-002) 2026-02-12
R-C03 Zica brand name has cultural sensitivity Avoided Rebranded to Drop (Alem decision 2026-02-09) 2026-02-09
R-C04 "Banking" language in UI creates regulatory exposure Mitigated Removed all "banking" references from UI (task #197) 2026-02-09
R-C05 SHA-256 password support creates rainbow table vulnerability Mitigated SHA-256 support removed; bcrypt-only policy enforced 2026-02-13

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-08 Approved (AI)
Reviewer John (AI Director) 2026-02-23 Reviewed
AI Director (John) John 2026-02-23 Approved
Project Sponsor Alem Bašić TBD — requires review

RACI Matrix: Drop — Fintech Payment App

RACI Matrix: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments Version: 1.0 Date: 2026-02-23 Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-23 John Initial draft — Drop-specific roles and activities

1. Purpose

This RACI matrix defines responsibility assignments for all Drop project activities. Drop is an AI-native internal product of ALAI Holding AS. Most "team" roles are filled by AI agents coordinated by John (AI Director). Alem Bašić (CEO) is the sole human, responsible for strategic decisions, partnerships, and regulatory submissions.

Conflict resolution: Disputes escalate to John (AI Director), then Alem (CEO) for strategic/financial issues.

2. RACI Definitions

Letter Role Definition
R Responsible Does the work
A Accountable Ultimately answerable; one per activity
C Consulted Provides input; two-way communication
I Informed Kept updated; one-way communication

3. Project Roles

Role Code Role Title Person / Agent Notes
CEO Chief Executive Officer Alem Bašić Strategic decisions, partnerships, budget, regulatory submissions
JD AI Director John (Claude Opus) Delivery accountability, architecture, agent coordination
BUILD Builder Agent Claude Sonnet (per-task) Feature implementation, API routes, frontend
VAL Validator Agent Claude Sonnet (per-task) Testing, validation, code review (read-only)
SEC Security Agent Claude (per-sprint) Threat modelling, security audit, compliance checks
LEGAL Legal Agent Claude (as needed) Regulatory review, document drafting
FIN Finance Agent Claude (as needed) Budget analysis, financial projections
EXT External Advisor TBD (human) Legal advisor for Finanstilsynet, BaaS contracts

4. RACI Matrix — Project Phases & Activities

4.1 Project Initiation & Planning

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Project Charter I A C
Project Brief I A C C
Budget approval A C R
Risk Register (initial) I A C C C
RACI Matrix I A
Stakeholder identification C A R
Communication Plan I A

4.2 Requirements & Analysis

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Business Requirements Document (BRD) C A R R
Functional Requirements (FRS) C A R C
Non-Functional Requirements C A R C
User Stories I A R
Acceptance Criteria I A R C
Requirements Traceability Matrix I A R C
Regulatory requirements mapping C C A R

4.3 Architecture & Design

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
System architecture (ADRs) I A R C
Database schema design I A R C
API contract design I A R C
Security architecture I C A
PSD2 pass-through model design I A R C C
UI/UX design (Figma) I A
Infrastructure design (Fly.io / Docker) I A R

4.4 Development

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Backend API routes (26 endpoints) A R C
Frontend pages (Next.js — 10 screens) A R
Database schema + migrations A R C
Authentication (JWT + BankID mock) A R C
Remittance flow implementation A R C
QR payment flow implementation A R C
Merchant dashboard implementation A R
Feature flags implementation A R
CI/CD pipeline (GitHub Actions) A R
Docker containerisation A R
Code review A R
Unit test writing A R C

4.5 Security Hardening (Phase 0.5)

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Security audit (full codebase) I C A
JWT secret hardening A R C
CVV/card data removal A R C
CSRF protection implementation A R C
Rate limiting (persistent) A R C
CSP headers implementation A R C
Session management A R C
Demo credential removal A R C
Compliance documentation (gap analysis) I C A R
Penetration testing (pre-launch) I C C A

4.6 Testing & QA

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Test strategy I A C R C
Test plan I A C R
Unit tests (Vitest — 40 tests) A R C
Integration tests (20+ tests) A R C
E2E tests (Playwright — 3 projects) A C R
Performance tests (benchmarks) A C R C
Security tests (input chaos) A C R A
Regression tests A R C
Definition of Done validation A R
Go/No-Go decision A C R C

4.7 Compliance & Regulatory

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
PSD2 regulatory gap analysis C C R A
GDPR compliance review C C C A
AML/KYC compliance setup C C C A R
Finanstilsynet PISP/AISP registration A C C R
Legal terms + privacy policy C C A
BaaS partner contract negotiation A C C R

4.8 Deployment & Launch

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Deployment checklist I A C C C
Staging deployment (Fly.io) I A R C
Production deployment I A R R C
Monitoring + alerting setup I A R
App Store submission (iOS) I A R
Google Play submission (Android) I A R
Go-live communication A C
Merchant onboarding (200 targets) A I
Post-launch monitoring (48h) I A R

4.9 Post-Launch & Maintenance

Activity / Deliverable CEO JD BUILD VAL SEC LEGAL FIN EXT
Post-launch review (30 days) C A R R
Bug fix triage + resolution I A R C
Performance optimisation I A R C
Lessons learned documentation I A R R C C C
Incident response I A R C
Monthly financial reporting A C R
User feedback analysis C A R
Project closure sign-off A C

5. Escalation Matrix

Escalation Level Trigger Escalate To Response Time
L1 Task-level blocker John (JD) 4 hours
L2 Architecture/scope dispute John (JD) 4 hours
L3 Strategic/financial decision Alem (CEO) 24 hours
L4 Legal/regulatory blocker Alem + External Advisor 48 hours

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-23 Approved (AI)
AI Director (John) John 2026-02-23 Approved
Project Sponsor / CEO Alem Bašić TBD

Communication Plan: Drop — Fintech Payment App

Communication Plan: Drop — Fintech Payment App

Project: Drop — Remittance + QR Payments Version: 1.0 Date: 2026-02-23 Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO)

Document History

Version Date Author Changes
0.1 2026-02-23 John Initial draft — Drop-specific communication structure

1. Communication Objectives

Drop is an AI-native internal product of ALAI Holding AS. Communication is primarily between John (AI Director) and Alem Bašić (CEO), with AI agents reporting asynchronously. Objectives:

  1. Transparency — Alem always knows Drop status, blockers, and decisions at a glance
  2. Alignment — Requirements and priorities confirmed before implementation begins
  3. Accountability — Blockers surfaced immediately; decisions recorded in comms/decisions/
  4. Regulatory readiness — All compliance-relevant decisions documented for Finanstilsynet
  5. Documentation — Drop is AI-native; decisions persist in comms/decisions/ and HiveMind

2. Stakeholder Communication Needs

Stakeholder Role Information Needs Channel Frequency Detail Level
Alem Bašić CEO / Sponsor Milestone status, budget, strategic risks, partner decisions Direct session Weekly + ad-hoc Executive summary
John AI Director Full project status, risks, agent output, technical decisions Mission Control Daily Detailed
AI Builder agents Implementers Task specs, acceptance criteria, schema refs Task prompt Per-task Technical
AI Validator agents QA Feature to validate, test criteria, DoD Task prompt Per-task Technical
SpareBank1 / BaaS partners External partners Drop capabilities, partnership terms Email via Alem Quarterly + as needed Executive
Finanstilsynet Regulator PISP/AISP registration documentation Formal submission Annual + milestones Formal
Waitlist users Early adopters Launch updates, beta invitations Email (hei@getdrop.no) Monthly Simple
Local merchants Merchant users Onboarding, QR setup, fee structure In-person + email On onboarding Simple

3. Communication Channels & Tools

Channel Tool Purpose Access
AI Director ↔ CEO sessions Direct Claude session Strategic decisions, major blockers, reviews Alem + John
Task management Mission Control (mc.js) Task status, agent coordination John + agents
Decision records comms/decisions/ (ADRs) Architectural and strategic decisions All team
Knowledge base BookStack (localhost:6875) Documentation, guides, specs All team
Persistent memory HiveMind (hivemind.js) Cross-session learnings, agent intel John + agents
Email (external) MCP email — john / info accounts Partner communications, waitlist, regulatory John + Alem
Partner documents Documenso (sign.basicconsulting.no) Contracts, NDAs, formal agreements Alem
Slack alai-talk.slack.com Optional team-wide announcements Alem + John
Incident reports project/docs/incident-report.md Production incidents John

4. Meeting Schedule

4.1 Regular Ceremonies (AI-Native Cadence)

Meeting Purpose Frequency Format Facilitator Output
Sprint Planning Backlog review, task assignment to agents Every 2 weeks Async (John prepares) + Alem review John Sprint tasks in Mission Control
Sprint Review Demo completed features Every 2 weeks Alem session — John demos John Sprint log entry in PIPELINE.md
Sprint Retrospective Process improvement, learning opportunity Every 2 weeks Async by John + /learning-opportunity John Updated MEMORY.md / rules
Weekly Status Check Drop status for Alem Weekly Written status in HiveMind + direct session if needed John Status report
Risk Review Update risk register Weekly Embedded in sprint planning John Updated risk-register.md
Strategic Review Partner decisions, regulatory updates Monthly Alem session Alem Decision record

4.2 Event-Triggered Communications

Trigger Action Channel Response Time
New critical risk (Score ≥ 15) Escalate to Alem Direct session Within 4 hours
Security incident Incident report + Alem notification Direct + email Immediately
BaaS partner response received Alem briefing + decision session Direct session Within 24 hours
Milestone completed Update PIPELINE.md + notify Alem HiveMind post Same day
Finanstilsynet correspondence Legal review + Alem briefing Direct + email Within 48 hours
Agent task failure / blocked John investigation + Alem if strategic Mission Control Within 4 hours

5. Reporting Cadence

Report Frequency Prepared By Audience Location
Sprint Report Per sprint John Alem PIPELINE.md sprint log
Weekly Status Weekly John Alem HiveMind + direct session
Risk Report Monthly John Alem risk-register.md
Budget Report Monthly Finance agent Alem comms/reports/
Milestone Report Per milestone John Alem + partners PIPELINE.md + email
Security Report Per sprint Security agent John + Alem security/ directory
Post-launch Report 30 days post-launch John Alem + investors comms/reports/

5.1 Weekly Status Template

SUBJECT: Drop — Weekly Status — Week of [DATE]

STATUS: ON TRACK / AT RISK / DELAYED

PHASE: [Current phase from ROADMAP.md]
STAGING: https://drop-staging.fly.dev/ — [UP/DOWN]

THIS WEEK:
- [completed item 1]
- [completed item 2]

NEXT WEEK:
- [planned item 1]
- [planned item 2]

BLOCKERS:
- [blocker] → [action needed from Alem]

TOP RISKS:
| Risk | Score | Status |
|------|-------|--------|
| [R-001] BaaS partner | 20 | [current status] |

DECISIONS NEEDED FROM ALEM:
- [ ] [decision by date]

6. Escalation Paths

Level Trigger Escalate To Channel Response SLA
L1 Agent blocker (technical) John (self-resolve) Mission Control 4 hours
L2 Architecture decision required John (makes decision) ADR in comms/decisions/ Same day
L3 Strategic / partnership decision Alem Direct session 24 hours
L4 Budget change > 10% Alem Direct session 24 hours
L5 Legal / regulatory blocker Alem + external legal Email + direct 48 hours
P1 Security incident / data breach Alem immediately Direct + email 15 minutes

7. Documentation Standards

7.1 File Naming Convention

[DOCUMENT_TYPE]-[DATE]-[VERSION].[ext]
Example: drop-sprint-report-2026-02-20-v1.0.md
Example: drop-meeting-notes-2026-02-20.md

7.2 Document Storage Locations

Document Type Location
Project governance (charter, brief, RACI, risks) docs/PROJECT-GOVERNANCE/
Business requirements docs/BUSINESS-REQUIREMENTS/
Decision records / ADRs comms/decisions/
Meeting notes comms/meetings/
Status reports comms/reports/
Partner communications comms/client/
Technical documentation docs/ (see INDEX.md)
Security reports security/

7.3 Decision Record Format (ADR)

All significant decisions must be logged in comms/decisions/ as ADR files:

# ADR-XXX: [Decision Title]

**Date:** YYYY-MM-DD
**Status:** Proposed | Accepted | Deprecated | Superseded
**Decider:** [Name/Agent]
**Context:** [Why this decision was needed]
**Decision:** [What was decided]
**Consequences:** [What changes as a result]
**Alternatives considered:** [What else was evaluated]

8. External Communication Protocols

Communication Type Authorized Approval Required Notes
BaaS partner updates Alem None Document outcomes
Finanstilsynet submissions Alem + Legal advisor Alem sign-off Formal; keep copies
Press / public statements about Drop Alem only Alem No product details without approval
Merchant onboarding comms Alem None Track in merchant dashboard
Waitlist email updates John Alem approval for major announcements Via MCP email — info account
Investor communications Alem Alem John prepares materials

9. Crisis Communication Plan

9.1 Crisis Triggers

9.2 Crisis Protocol

  1. Identify — John identifies crisis; logs in project/docs/incident-report.md
  2. Contain — John assesses scope and implements immediate mitigations (within 1 hour)
  3. Escalate — John notifies Alem via direct session within 1 hour of identification
  4. Communicate — John drafts external communication; Alem approves before sending
  5. Update — Alem and affected parties receive updates every 4 hours until resolved
  6. Resolve — Crisis closed when all impacts mitigated and systems restored
  7. Learn — /learning-opportunity skill run; memory updated; process improved

9.3 Crisis Communication Template

SUBJECT: [DROP — URGENT] [Crisis Summary]

Vi vil informere deg om en situasjon som påvirker Drop.

SITUASJON: [What happened]
PÅVIRKNING: [What is affected]
UMIDDELBARE TILTAK: [What we have done]
NESTE STEG: [What we will do]
FORVENTET LØSNING: [Timeline]

Neste oppdatering: [Next update time]

Kontakt: Alem Bašić — alem@alai.no — +47 40 47 42 51

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-23 Approved (AI)
AI Director (John) John 2026-02-23 Approved
CEO / Project Sponsor Alem Bašić TBD

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

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

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

2.3 Assumptions

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

2.4 Constraints

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

3. Stakeholder Register

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:

4. Budget Summary

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

# 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):

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

# 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

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

8. Governance Model

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

  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

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

# 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

Project Brief

Project Brief: {{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. Executive Summary

{{EXECUTIVE_SUMMARY_PARAGRAPH}}

2. Business Context & Market Opportunity

2.1 Business Context

{{BUSINESS_CONTEXT}}

2.2 Market Opportunity

Dimension Current State Opportunity
Market Size {{CURRENT}} {{OPPORTUNITY}}
Target Segment {{SEGMENT}} {{SEGMENT_SIZE}}
Growth Rate {{GROWTH}} {{PROJECTED}}
Key Trend {{TREND}} {{IMPLICATION}}

2.3 Strategic Fit

This project directly supports:

3. Problem Statement

3.1 Core Problem

{{PROBLEM_STATEMENT}}

3.2 Pain Points

# Pain Point Affected Stakeholder Measurable Impact
P-01 {{PAIN_POINT}} {{STAKEHOLDER}} {{IMPACT}}
P-02
P-03

3.3 Current State Gaps

Current Process/System: {{CURRENT_STATE_DESCRIPTION}}

Key Gaps:

Cost of Inaction: {{COST_OF_NOT_ACTING}} (e.g., $X/year in manual labor, X% churn risk, regulatory penalty)

4. Proposed Solution Overview

4.1 Solution Description

{{SOLUTION_DESCRIPTION}}

4.2 Key Capabilities

# Capability Addresses Pain Point Priority
CAP-01 {{CAPABILITY}} P-{{XX}} Must Have
CAP-02 Must Have
CAP-03 Should Have
CAP-04 Could Have

4.3 Solution Architecture (High Level)

graph LR
    A[{{USER_TYPE}}] --> B[{{FRONTEND}}]
    B --> C[{{BACKEND_API}}]
    C --> D[{{DATABASE}}]
    C --> E[{{EXTERNAL_SERVICE}}]

4.4 Platforms & Channels

5. Key Benefits & ROI Projection

5.1 Quantified Benefits

Benefit Category Description Estimated Annual Value
Revenue increase {{DESCRIPTION}} {{NOK_AMOUNT}}
Cost reduction {{DESCRIPTION}} {{NOK_AMOUNT}}
Risk reduction {{DESCRIPTION}} {{NOK_AMOUNT}}
Productivity gain {{DESCRIPTION}} {{NOK_AMOUNT}}
Total Annual Benefit {{TOTAL}}

5.2 ROI Calculation

Metric Value
Total Investment (Year 1) {{INVESTMENT}} NOK
Total Annual Benefit {{ANNUAL_BENEFIT}} NOK
Payback Period {{PAYBACK_MONTHS}} months
3-Year ROI {{ROI_PERCENTAGE}}%
Net Present Value (3yr) {{NPV}} NOK

Assumptions: {{ROI_ASSUMPTIONS}}

5.3 Qualitative Benefits

6. High-Level Requirements

# Requirement Type Priority Notes
HLR-01 {{REQUIREMENT}} Functional Must Have
HLR-02 Functional Must Have
HLR-03 Non-Functional Must Have {{E.G., GDPR compliance}}
HLR-04 Functional Should Have
HLR-05 Functional Could Have

7. Competitive Landscape

Alternative Type Strengths Weaknesses Why We Win
{{COMPETITOR_1}} Direct competitor {{STRENGTHS}} {{WEAKNESSES}} {{DIFFERENTIATION}}
{{COMPETITOR_2}} Indirect/substitute
{{COMPETITOR_3}} Build in-house alt

Our Unique Value Proposition: {{VALUE_PROPOSITION}}

8. Resource Requirements

8.1 Team

Role Effort Source
Project Manager {{ESTIMATE}} ALAI internal
Tech Lead {{ESTIMATE}} ALAI internal
Developer(s) {{ESTIMATE}} ALAI internal
Designer {{ESTIMATE}} ALAI internal / contract
QA {{ESTIMATE}} ALAI internal

8.2 Budget Summary

Category Estimated Cost (NOK)
Development {{AMOUNT}}
Design {{AMOUNT}}
Infrastructure {{AMOUNT}}
Licenses {{AMOUNT}}
Contingency (15%) {{AMOUNT}}
Total {{TOTAL}}

8.3 Timeline

Phase Duration Start
Planning & Requirements {{DURATION}} {{DATE}}
Design {{DURATION}} {{DATE}}
Development {{DURATION}} {{DATE}}
Testing & UAT {{DURATION}} {{DATE}}
Launch {{DURATION}} {{DATE}}
Total Duration {{TOTAL_DURATION}} {{START_DATE}}

9. Go / No-Go Decision Criteria

9.1 Go Criteria (ALL must be met)

9.2 No-Go Triggers (ANY is sufficient to stop)

9.3 Decision

Dimension Decision Decision Maker Date
Proceed with planning Go / No-Go / Hold {{DECISION_MAKER}}
Budget approved Yes / No / Conditional {{BUDGET_APPROVER}}
Resource allocation approved Yes / No {{RESOURCE_APPROVER}}

Approval

Role Name Date Signature
Author
Reviewer
AI Director (John)
Project Sponsor
CEO (Alem)

Risk Register

Risk Register: {{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. Risk Identification Methodology

Identification Methods Used:

Initial Risk Assessment Date: {{DATE}} Next Scheduled Review: {{DATE}} Risk Owner: {{RISK_OWNER}} (typically the Project Manager)

2. Risk Categories

Category Description Common Examples
Technical Technology failures, integration issues, performance, security API changes, infrastructure limits, unknown complexity
Resource Team availability, skill gaps, capacity constraints Key person sick leave, agent performance degradation
Client Client-side decisions, availability, requirement volatility Delayed approvals, changing priorities, unclear requirements
External Third-party dependencies, regulatory changes, market shifts API deprecation, GDPR change, competitor launch
Financial Budget overruns, payment delays, cost estimates Underestimated effort, currency exposure, vendor price change
Timeline Schedule risks, deadline pressure, estimation errors Milestone slip, hard deadline, dependency delays
Quality Defect rate, technical debt, process failures Insufficient testing, rushed delivery, poor documentation
Organizational Internal politics, process changes, leadership decisions Reprioritization, team restructure, tool changes

3. Risk Probability & Impact Scale

3.1 Probability Scale

Level Score Definition Example
Very Low 1 < 10% chance — rare, theoretical Unknown-unknown
Low 2 10–30% chance — unlikely but possible Historical precedent rare
Medium 3 30–50% chance — may occur Has happened on similar projects
High 4 50–70% chance — likely to occur Happens regularly
Very High 5 > 70% chance — almost certain Happened before on this type

3.2 Impact Scale

Level Score Schedule Impact Budget Impact Quality Impact
Negligible 1 < 1 day < 1% Minor fix needed
Minor 2 1–3 days 1–5% Some rework needed
Moderate 3 3–7 days 5–10% Significant rework
Major 4 1–2 weeks 10–20% Deliverable at risk
Critical 5 > 2 weeks > 20% Project failure risk

3.3 Risk Matrix (Probability × Impact)

         IMPACT →
         1(Neg) 2(Min) 3(Mod) 4(Maj) 5(Crit)
P  5(VH) |  5  |  10  |  15  |  20  |  25  |  ← CRITICAL ZONE (≥15)
R  4(H)  |  4  |   8  |  12  |  16  |  20  |
O  3(M)  |  3  |   6  |   9  |  12  |  15  |
B  2(L)  |  2  |   4  |   6  |   8  |  10  |  ← MEDIUM ZONE (5-14)
↑  1(VL) |  1  |   2  |   3  |   4  |   5  |  ← LOW ZONE (≤4)
Score Risk Level Response Required Escalation
1–4 LOW Monitor; review monthly PM awareness
5–9 MEDIUM Active mitigation plan required PM + Tech Lead
10–14 HIGH Immediate action + weekly review PM + John
15–25 CRITICAL Emergency response; may stop project John + Alem

4. Risk Appetite Statement

Overall Risk Appetite: {{LOW | MEDIUM | HIGH}}

Risk Category Appetite Rationale
Technical Medium Innovation requires technical experimentation
Financial Low Budget is fixed; overruns require CEO approval
Quality Low Client satisfaction is core to ALAI brand
Timeline Medium Some schedule flexibility acceptable if quality maintained
Security Very Low Zero tolerance for data breaches or compliance violations
Regulatory Very Low Legal exposure is unacceptable

Maximum Acceptable Risk Exposure: Score ≤ 9 without escalation to John. Escalation Threshold: Any risk scoring ≥ 10 must be reported to John within 24 hours.

5. Active Risk Register

ID Risk Description Category Prob (1-5) Impact (1-5) Score Response Strategy Owner Trigger Indicators Status Date Identified Review Date
R-001 {{RISK_DESCRIPTION}} Technical {{1-5}} {{1-5}} {{SCORE}} Mitigate {{OWNER}} {{TRIGGER}} Open {{DATE}} {{DATE}}
R-002 Key client contact unavailable for approvals Client 3 4 12 Mitigate PM Slow email responses; missed meetings Open {{DATE}} {{DATE}}
R-003 Third-party API deprecates required endpoint External 2 5 10 Mitigate Tech Lead Vendor changelog; API versioning notice Open {{DATE}} {{DATE}}
R-004 Scope creep from undiscovered requirements Client 4 3 12 Mitigate BA/PM Frequent "small" change requests Open {{DATE}} {{DATE}}
R-005 Performance targets not met under load Technical 3 4 12 Mitigate Tech Lead Slow response in dev testing Open {{DATE}} {{DATE}}
R-006 {{RISK_DESCRIPTION}} Open {{DATE}} {{DATE}}
R-007 Open
R-008 Open

6. Risk Response Strategies

Risk ID Strategy Response Actions Contingency Plan Resources Required
R-001 {{STRATEGY}} 1. {{ACTION_1}}; 2. {{ACTION_2}} {{CONTINGENCY_IF_RISK_OCCURS}} {{RESOURCES}}
R-002 Mitigate 1. Identify backup decision-maker; 2. Set approval deadlines in contract; 3. Async approval process Escalate to John → client sponsor PM time: 2h/week
R-003 Mitigate + Accept 1. Abstract API calls behind service layer; 2. Monitor vendor changelog; 3. Build integration tests Switch to alternative vendor; allocate 3-day buffer Tech Lead: 1 day setup
R-004 Avoid + Mitigate 1. Detailed BRD sign-off before development; 2. Formal change request process enforced; 3. Weekly scope review Raise change request; negotiate timeline/budget BA: 2h/week scope monitoring

Response Strategy Definitions

Strategy When to Use Action
Avoid High score + feasible to eliminate Change plan to remove the risk source
Mitigate Cannot avoid; must reduce probability or impact Implement controls, monitoring, early warning systems
Transfer Risk can be shared with third party Insurance, contractual liability transfer, outsourcing
Accept (Active) Low score; mitigation cost > risk cost Monitor and create contingency plan
Accept (Passive) Negligible score Acknowledge, no action required
Escalate Exceeds project authority or appetite Raise to John / Alem / client sponsor

7. Risk Heat Map

quadrantChart
    title Risk Heat Map — {{PROJECT_NAME}}
    x-axis Low Impact --> High Impact
    y-axis Low Probability --> High Probability
    quadrant-1 "CRITICAL — Immediate Action"
    quadrant-2 "HIGH — Active Management"
    quadrant-3 "LOW — Monitor"
    quadrant-4 "MEDIUM — Watch"
    R-001: [0.7, 0.5]
    R-002: [0.6, 0.5]
    R-003: [0.8, 0.3]
    R-004: [0.5, 0.7]
    R-005: [0.7, 0.5]

Update coordinates as Probability/Impact scores change. X = Impact/5, Y = Probability/5.

8. Escalation Thresholds

Threshold Action Responsible Timeframe
Any new risk Score ≥ 15 Immediate escalation to John + Alem PM Within 4 hours of identification
Any existing risk score increases by ≥ 5 Escalate to John PM Within 24 hours
> 3 risks at Score ≥ 10 simultaneously Emergency risk review meeting PM + John Within 48 hours
Any risk triggers its contingency plan Notify all stakeholders PM Immediately
Risk causes milestone slip > 3 days Formal change request + escalation PM Within 24 hours

9. Risk Review Schedule

Frequency Activity Participants Output
Weekly (Sprint Planning) Review all active risks, update scores/status PM, Tech Lead Updated register
Sprint Retrospective Identify new risks; close resolved risks Full team New risks added
Monthly Full risk register review + heat map update PM, John Risk report to stakeholders
Ad-hoc New risk identified (any time) Risk identifier + PM New risk logged within 24h
Milestone Risk review before each major milestone PM, Tech Lead, John Go/no-go input

Review Log

Date Reviewer Risks Reviewed New Risks Added Risks Closed Key Changes
{{DATE}} {{NAME}} {{COUNT}} {{COUNT}} {{COUNT}} {{SUMMARY}}

10. Closed / Accepted Risks Archive

ID Risk Description Resolution Type Resolution Notes Date Closed
R-999 Example: Third-party payment provider delays Mitigated Switched to backup provider; no impact {{DATE}}

Approval

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

RACI Matrix

RACI Matrix: {{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. Purpose & How to Use This Matrix

This RACI matrix defines responsibility assignments for all activities and deliverables in the {{PROJECT_NAME}} project. It serves as the authoritative reference for:

Conflict resolution: When disagreements arise about ownership, refer to this document. Disputes escalate to the Accountable party, then to John (AI Director) if unresolved.

2. RACI Definitions

Letter Role Definition Rule
R Responsible The person(s) who do the work to complete the activity Can be multiple per activity
A Accountable The one person who is ultimately answerable; signs off on completion MUST be exactly ONE per activity
C Consulted Provides expertise/input; two-way communication required Optional; should be minimized
I Informed Kept up to date on decisions/progress; one-way communication Should be only those who need to know

Common Mistakes to Avoid:

3. Project Roles

Role Code Role Title Person / Agent Org Notes
CEO Chief Executive Officer Alem ALAI Strategic decisions, final budget approval
JD AI Director John ALAI Delivery accountability, agent coordination
PM Project Manager {{NAME/AGENT}} ALAI Day-to-day coordination, reporting
PO Product Owner {{NAME/AGENT}} ALAI / Client Backlog, requirements prioritization
BA Business Analyst {{NAME/AGENT}} ALAI Requirements elicitation, documentation
TL Tech Lead {{NAME/AGENT}} ALAI Architecture, code review, technical decisions
DEV Developer(s) {{NAME/AGENT}} ALAI Feature implementation
DES Designer {{NAME/AGENT}} ALAI / Contract UI/UX, visual assets
QA QA Engineer {{NAME/AGENT}} ALAI Test planning, execution, sign-off
OPS DevOps / Infrastructure {{NAME/AGENT}} ALAI CI/CD, deployment, monitoring
CS Client Sponsor {{NAME}} {{CLIENT}} Executive decisions, final acceptance
CPO Client Product Owner {{NAME}} {{CLIENT}} Day-to-day client requirements

4. RACI Matrix — Project Phases & Activities

4.1 Project Initiation & Planning

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Project Charter creation I A R C C C C I
Project Brief / Proposal I A R R R C I I
Budget approval A C I I I
Stakeholder identification I C R C R A C
Communication Plan I C A C R I I
Risk Register (initial) I C A C C R C I
RACI Matrix I A R C I
Project kick-off meeting I A R R R R R R R R A R

4.2 Requirements & Analysis

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Discovery workshops I I C A R C C R
Business Requirements Doc (BRD) I C I A R C C R
Functional Requirements (FRS) I C I A R R C C C I R
Non-Functional Requirements I C I C R A C C C I C
User Stories (backlog creation) I I I A R C C I R
Requirements sign-off A C I C R I A R
Requirements Traceability Matrix I I I A R C R I I

4.3 Design

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
UX research / user flows I I I C C A I R
Wireframes I I I C C A I R
High-fidelity mockups I I I C C A R C
Design system / style guide I I I C C C A I I
Design review & approval I C I C C R A C
Technical architecture design I C I C C A R C
Architecture Decision Records (ADRs) I C A R C
Database schema design I I C C A R C
API contract design I I C C A R
Infrastructure design I I C A

4.4 Development

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Sprint planning I C A C C R C I
Feature implementation I I I C A
Code review I A R
Unit test writing I C A C
Integration development I C A R C
UI implementation I C C R A
Daily standup I A R R R R R R R
Sprint demo I R A R R R R R R I R
Sprint retrospective I A R R R R R R R
Technical documentation I A R

4.5 Testing & Quality Assurance

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Test plan creation I I C C C A I
Test case creation I C C C C A I
Unit testing execution I C R A
Integration testing I C R A C
Performance testing I C C A C I
Security testing C I C A C
UAT preparation R A R R I C
UAT execution I C C R A
UAT sign-off I C I C C A R
Defect triage I C C R A
Regression testing I C R A
Go/No-Go decision I A C C C R C C C

4.6 Deployment & Launch

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Deployment checklist C I C C C A
Staging deployment I I C R R A
Production deployment C I I C R R A
DNS / SSL setup C A
Monitoring / alerting setup I C A
Go-live communication I I A R I R
Launch announcement I I A R C C C
Post-launch monitoring (48h) C I C R A I

4.7 Post-Launch & Maintenance

Activity / Deliverable CEO JD PM PO BA TL DEV DES QA OPS CS CPO
Post-launch review (30 days) I C A R R R R R R C R
Lessons learned documentation I C A R R R R R R R I I
Handover documentation I C A R R A R R R C I
Bug fix triage I A C R R I C
Performance optimization I C A R C C
Client training C C R C I A
Project closure sign-off A C R A

5. Escalation Matrix

Escalation Level Trigger Escalate To Response Time Resolution Time
L1 Task-level disagreement Tech Lead (technical) / PM (process) 4 hours 1 business day
L2 Role/accountability dispute PM + John 4 hours 1 business day
L3 Scope/priority conflict John + PO 2 hours Same day
L4 Contract/budget/strategic decision John + Alem 4 hours 2 business days
L5 External/client dispute Alem + Client Sponsor 24 hours 3 business days

6. Handling Common RACI Conflicts

Issue: Multiple people marked A on same activity Action: Hold a 15-minute meeting; the most senior person or domain owner retains A; others become R or C.

Issue: No one marked R on an activity Action: PM escalates to John immediately. A without R = activity will not get done.

Issue: Too many C's (>4) on a single activity Action: Review each C — can they be demoted to I? Consult only those who provide unique value.

Issue: Key stakeholder says "I didn't know about X" Action: Review their I assignments; add missing I designations; improve communication plan frequency.

Issue: Team member disputes their R assignment Action: Discuss with PM; if skill gap, arrange training or reassign; document decision.

7. Review Cadence

Trigger Review Type Owner
Project phase change Full matrix review PM
New team member joins Role assignments update PM
Team member leaves Responsibility reassignment PM
Scope change approved Impact on roles PM + PO
Monthly Sanity check; any gaps? PM
Project retrospective Lessons for next RACI PM

Approval

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

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

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

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

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

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

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

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

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

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

8. External Communication Protocols

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

9.1 Crisis Triggers

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