# Project Pipeline Framework & Next-Batch IT Handover Guide

---

## 1. Pipeline Integration Architecture

To establish Impact Hub Ibadan’s flagship innovation programme, all initiatives must flow through a unified **5-Stage Innovation Pipeline**. This structure unifies two critical pipelines:
1. **Existing Active Projects**: Internal ventures already under development by Impact Hub Ibadan.
2. **New Student Wishlist Projects**: Promising ideas discovered through the Student Innovators Onboarding Form.

```mermaid
flowchart TD
    subgraph Intake["Stage 0: Pipeline Intake"]
        EP["Existing Impact Hub Ibadan Projects"] --> AUDIT["Technical & Commercial Audit"]
        NP["New Student Onboarding Submissions"] --> SCREEN["Wishlist Scoring & Screening"]
    end

    AUDIT --> S1["Stage 1: Idea Refinement & Co-Founder Alignment"]
    SCREEN --> S1

    S1 --> G1{"Gate 1: Problem & Team Validated?"}
    G1 -- Yes --> S2["Stage 2: Market Testing & PMF Discovery"]
    G1 -- No --> REV1["Pivot or Revise Charter"]

    S2 --> G2{"Gate 2: Empirical Demand Proven?"}
    G2 -- Yes --> S3["Stage 3: Rapid MVP Prototyping"]
    G2 -- No --> REV2["Pivot Value Prop / Re-test"]

    S3 --> G3{"Gate 3: Active Users & Stable MVP?"}
    G3 -- Yes --> S4["Stage 4: Market Pilot & Demo Showcase"]
    G3 -- No --> BUG["Bug Bash & Sprint Iteration"]

    S4 --> HANDOVER["Standardized Handover to Next IT Batch"]
```

---

## 2. Stage-Gate Evaluation Rubric

Every project in the pipeline must pass through four strict milestone gates before advancing:

| Stage | Name | Key Activity | Gate Criteria to Advance |
| :--- | :--- | :--- | :--- |
| **Stage 0** | **Intake & Audit** | Ingestion of existing codebases or screening of onboarding wishlist entries. | Clear problem statement, assigned project lead, initial architecture review. |
| **Stage 1** | **Refine & Align** | Problem-solution canvas, team role alignment, IP/commitment agreement. | **Signed Team Charter** and **Approved Lean Canvas**. |
| **Stage 2** | **Market Testing** | Customer interviews, competitive differentiation, smoke-test landing pages. | **30+ Documented Interviews** and **>10% Waitlist Conversion** on smoke test. |
| **Stage 3** | **MVP Engineering** | Agile sprints, core user journey build, security audits, alpha deployment. | **Functional Staging & Production Build** with **>=25 Active Alpha Users**. |
| **Stage 4** | **Market Readiness** | Public pilot launch, unit economics modeling, pitch deck, documentation. | **100+ Active Users/Pilot MoU**, **Pitch Deck**, and **Complete Handover Dossier**. |

---

## 3. Auditing Existing Internal Projects

For projects currently being developed at Impact Hub Ibadan, the team must complete the following audit protocol:

### Step 1: Technical Stack & Repository Hygiene Audit
- [ ] Is source code hosted in the official Impact Hub Ibadan GitHub organization?
- [ ] Does a comprehensive `README.md` exist explaining local setup, environment variables, and architecture?
- [ ] Are all dependencies cleanly declared (`package.json`, `requirements.txt`, `pubspec.yaml`, etc.)?
- [ ] Does the project compile, build, and run locally without unpublished private assets?
- [ ] Are API keys and secrets stored safely outside git tracking (`.env.example` provided)?

### Step 2: Commercial & Customer Validation Audit
- [ ] Has the project been tested with real users, or has it only been tested by the developers?
- [ ] What is the exact customer persona?
- [ ] What is the current user traction metric (active users, transaction volume, or pilot partners)?
- [ ] Has the business model or monetization pathway been formulated?

### Step 3: Classification & Pipeline Assignment
Based on the audit, assign the existing project to its appropriate stage:
- If code exists but **no customer validation** has taken place: Route to **Stage 2 (Market Testing)**.
- If code is unstable or incomplete: Route to **Stage 3 (MVP Sprint)** with prioritized refactoring tasks.
- If product is working and validated: Route to **Stage 4 (Market Readiness & Pilot Expansion)**.

---

## 4. Standardized Project Dossier Template

Every project in the pipeline must maintain an up-to-date **Project Dossier** in Markdown within its repository at `/docs/PROJECT_DOSSIER.md`.

```markdown
# [Project Name] — Innovation Dossier

## 1. Project Snapshot
- **Pipeline Stage**: [Stage 1 / Stage 2 / Stage 3 / Stage 4]
- **Project Lead / Champion**: [Name, Email, WhatsApp]
- **Team Members & Roles**: 
  - Hacker / Tech Lead: [Name]
  - Designer / UI Lead: [Name]
  - Hustler / Product & Growth Lead: [Name]
- **Repository URL**: [GitHub Link]
- **Live Staging / Production URL**: [URL]
- **Figma Design File**: [Figma Link]

## 2. Problem Statement & Unique Value Proposition
- **Validated Problem**: [Clear description of user pain point]
- **Target Customer**: [Specific persona and demographic]
- **Unique Value Proposition (UVP)**: [Why this solution wins over alternatives]

## 3. Validation Metrics & Evidence
- **Number of User Interviews Completed**: [e.g., 34]
- **Smoke Test Conversion Rate**: [e.g., 14.2% on 320 visitors]
- **Current Active Users (WAU)**: [e.g., 45]
- **Key Customer Insights**: [Top 3 lessons learned from real users]

## 4. Technical Architecture & Stack
- **Frontend**: [e.g., React / Next.js / Tailwind CSS]
- **Backend**: [e.g., Node.js / Express / Python FastAPI]
- **Database**: [e.g., PostgreSQL / Supabase]
- **Hosting / Infra**: [e.g., Vercel + Railway]
- **Third-Party Services**: [e.g., Paystack for payments, SendGrid for emails]

## 5. Current Backlog & Immediate Next Steps
- [ ] Task 1
- [ ] Task 2
- [ ] Task 3

## 6. Known Bugs & Technical Debt
- [Document any known issues or performance bottlenecks]
```

---

## 5. Handover Protocol for the Next Batch of IT Students

To eliminate downtime between the departure of the current IT student batch and the arrival of the next batch, execute this structured transition:

### A. The 3-Tier Handover Package
1. **The Code Repository Tier**:
   - Clean git history with all feature branches merged to `main` or properly labeled.
   - Fully working `.env.example` file.
   - Automated setup scripts (e.g., `npm run setup` or Docker Compose).
2. **The Documentation Tier**:
   - Standardized `PROJECT_DOSSIER.md` filled out for 100% of pipeline projects.
   - Video walk-through: A 5–10 minute Loom / screen recording demonstrating system architecture, database structure, and key admin workflows.
   - User database export and customer feedback logs.
3. **The Governance Tier**:
   - Updated **Quarterly Plan** and backlog prioritized in Jira / GitHub Projects / Trello.
   - Roster of active student innovators from the rolling onboarding pipeline ready to collaborate.

---

### B. Two-Week Transition Schedule for Incoming IT Students

```
+----------------------------------------------------------------------------------------------------+
|                                    INCOMING IT BATCH ONBOARDING                                    |
+--------------------------------------------------+-------------------------------------------------+
|               WEEK 1: ORIENTATION                |                WEEK 2: EXECUTION                |
+--------------------------------------------------+-------------------------------------------------+
| Day 1: Programme Blueprint & Mission Briefing    | Day 6: Pair Programming & Code Walkthrough     |
| Day 2: Pipeline Review & Project Assignments     | Day 7: Customer Interview & User Logs Shadowing |
| Day 3: Local Dev Environment Setup & Builds      | Day 8: First Feature PR / Bug Fix Submission   |
| Day 4: Review of Customer Interview Records      | Day 9: Sprint Planning for Incoming Quarter     |
| Day 5: Q&A with Outgoing IT Project Leads        | Day 10: Formal Handover Sign-Off & Independence |
+--------------------------------------------------+-------------------------------------------------+
```

#### Detailed Breakdown:

- **Day 1: SIP Orientation**:
  Incoming IT students read the *SIP Master Blueprint* and understand Impact Hub Ibadan's mission as an innovation incubator/accelerator hybrid.
- **Day 2: Project Allocation**:
  Review the active pipeline tracker. Students are matched to projects based on their skills and preferences declared in their onboarding form.
- **Day 3: "Day One Build" Test**:
  Every incoming student must clone their assigned repository and achieve a successful local build within 4 hours. Any difficulty reveals documentation defects that are immediately corrected.
- **Day 4–5: Knowledge Transfer Sessions**:
  Outgoing IT leads host interactive briefing sessions demonstrating live systems, edge cases, and user feedback.
- **Week 2: Supervised Execution**:
  Incoming students fix their first assigned bug or deploy their first small enhancement with outgoing leads reviewing the Pull Request.
- **End of Week 2: Official Torch Passing**:
  Incoming leads assume full repository ownership and administrative rights.

---

## 6. Sustainable Innovation Pipeline Continuity Matrix

| Risk Factor | Potential Failure Mode | Mitigation Strategy in Handover Guide |
| :--- | :--- | :--- |
| **Knowledge Loss** | Outgoing students graduate or finish placement; code context is lost. | Mandatory `PROJECT_DOSSIER.md` + 10-minute video walkthrough for every project. |
| **Abandonment** | High-potential student projects stop when placement ends. | Projects are institutionalized within Impact Hub Ibadan's pipeline; incoming IT students take over active sprints. |
| **Duplicate Work** | New batch starts building an idea that was already tested or failed. | Centralized Pipeline Tracker records historical validation experiments and pivot records. |
| **Onboarding Delay** | New interns spend weeks figuring out what to do. | 2-week structured onboarding schedule with the "Day One Build" test ensures immediate productivity. |