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

---

<!-- GUIDANCE: This document is an executive summary designed to secure stakeholder buy-in and
budget approval BEFORE a full project charter is written. Keep it concise (4-8 pages max)
but substantive. Decision-makers need enough detail to say "go" or "no-go". -->

## 1. Executive Summary

<!-- GUIDANCE: One paragraph (max 150 words) that answers: What is the problem? What is the solution?
Why now? What does success look like? Who delivers it? What does it cost?
Write this LAST, after completing all other sections. -->

> {{EXECUTIVE_SUMMARY_PARAGRAPH}}

---

## 2. Business Context & Market Opportunity

<!-- GUIDANCE: Describe the business environment, market dynamics, and strategic context.
Why is this the right moment for this project? What market forces (competition, regulation,
technology shift, customer demand) make this urgent? Include data where possible. -->

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

<!-- GUIDANCE: Explain how this project connects to the organization's strategic goals.
Reference specific OKRs, annual priorities, or board-level initiatives if applicable. -->

This project directly supports:
- **Strategic Goal:** {{STRATEGIC_GOAL}}
- **OKR / Initiative:** {{OKR_REFERENCE}}
- **Alignment with ALAI mission:** {{ALIGNMENT_EXPLANATION}}

---

## 3. Problem Statement

<!-- GUIDANCE: Define the problem with precision. A good problem statement is specific, measurable,
and separates symptoms from root causes. Include quantitative data where possible.
Avoid jumping to solutions here — that comes in section 4. -->

### 3.1 Core Problem

{{PROBLEM_STATEMENT}}

### 3.2 Pain Points

<!-- GUIDANCE: List the specific pain points experienced by affected stakeholders.
Each pain point should connect to a measurable impact (time lost, revenue lost, risk created). -->

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

### 3.3 Current State Gaps

<!-- GUIDANCE: Describe what exists today and where it falls short. What workarounds do people use?
What manual processes exist? What risks does the current state create? -->

**Current Process/System:** {{CURRENT_STATE_DESCRIPTION}}

**Key Gaps:**
- {{GAP_1}}
- {{GAP_2}}
- {{GAP_3}}

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

---

## 4. Proposed Solution Overview

<!-- GUIDANCE: Describe the solution at a high level — what will be built, for whom, and how it
solves the stated problem. Avoid technical implementation details here.
Focus on capabilities and outcomes, not architecture. -->

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

<!-- GUIDANCE: Replace with a simple diagram showing major components.
Don't need full technical depth — just enough for decision-makers to understand the solution shape. -->

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

### 4.4 Platforms & Channels

- [ ] Web Application
- [ ] iOS Mobile App
- [ ] Android Mobile App
- [ ] API / Backend Service
- [ ] Admin Dashboard
- [ ] Other: {{SPECIFY}}

---

## 5. Key Benefits & ROI Projection

<!-- GUIDANCE: Quantify benefits wherever possible. Decision-makers need to justify the investment.
ROI projection should be conservative — better to under-promise and over-deliver. -->

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

<!-- GUIDANCE: Benefits that are real but hard to quantify — brand, morale, compliance, risk posture. -->

- **Brand/Reputation:** {{BRAND_BENEFIT}}
- **Competitive Advantage:** {{COMPETITIVE_BENEFIT}}
- **Risk Reduction:** {{RISK_BENEFIT}}
- **Employee/User Experience:** {{UX_BENEFIT}}

---

## 6. High-Level Requirements

<!-- GUIDANCE: List the most critical functional and non-functional requirements at a business level.
This is NOT a detailed requirements document — that comes in the BRD/FRS phase.
Focus on the requirements that most influence scope, cost, and timeline. -->

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

<!-- GUIDANCE: Understand what alternatives exist — both direct competitors and substitute solutions.
Why is this proposed solution better or more appropriate than the alternatives? -->

| 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

<!-- GUIDANCE: Summarize the resources needed. High-level only — detailed staffing plan in the charter.
This section helps decision-makers understand the ask before approving full planning. -->

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

<!-- GUIDANCE: Define the conditions under which this project should proceed vs. be stopped or redesigned.
These criteria protect stakeholders from committing to a project that shouldn't proceed. -->

### 9.1 Go Criteria (ALL must be met)

- [ ] Budget approved: {{BUDGET_THRESHOLD}}
- [ ] Key stakeholders aligned on scope and timeline
- [ ] {{CRITICAL_DEPENDENCY}} confirmed available
- [ ] Legal/compliance review completed
- [ ] {{ADDITIONAL_GO_CRITERION}}

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

- [ ] Budget approval exceeds {{THRESHOLD}}% above estimate
- [ ] Critical dependency {{DEPENDENCY}} unavailable within {{TIMEFRAME}}
- [ ] Regulatory/legal blocker identified
- [ ] {{ADDITIONAL_NO_GO_TRIGGER}}

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