DOMAIN:PROJECT_MANAGEMENT:DELIVERY_LIFECYCLE

OWNER: faye (Team Alpha PM), sytske (Team Beta PM) UPDATED: 2026-03-24 SCOPE: full project lifecycle from intake to go-live PREREQUISITE: work-package-design.md (WP decomposition skills)

---

PRINCIPLE: GATES_PREVENT_WASTE

RULE: no phase begins until the previous phase's gate is passed. RULE: gates are binary — pass or fail. No "pass with caveats." RULE: a failed gate means rework in the current phase, not proceeding with known issues. REASON: in agentic development, rework is expensive. Agents rebuild context from scratch every session. Catching issues early (spec phase) costs 10x less than catching them late (integration testing).

---

THE_GE_DELIVERY_PIPELINE

PHASE 1: INTAKE          → Gate: Scope Brief Approved
PHASE 2: CONTRACT         → Gate: Contract Signed + Payment
PHASE 3: SCOPING          → Gate: Functional Spec Approved
PHASE 4: SPECIFICATION    → Gate: Formal Spec Approved
PHASE 5: DESIGN           → Gate: DESIGN.md Approved
PHASE 6: PLANNING         → Gate: WP Set Approved
PHASE 7: DEVELOPMENT      → Gate: All WPs Complete + Tests Pass
PHASE 8: INTEGRATION      → Gate: Integration Tests Pass
PHASE 9: UAT              → Gate: Client Sign-off
PHASE 10: DEPLOYMENT      → Gate: Production Healthy
PHASE 11: HANDOFF         → Gate: Operations Docs Complete

---

PHASE_1: INTAKE

OWNER: dima (Intake Specialist) ZONE: PUBLIC (pre-paywall) DURATION: 15-30 minutes (single conversation)

ACTIVITIES

• Discovery conversation with client (see intake-methodology.md)
• Understand business context, problem, desired outcome
• Categorize MVP vs future features
• Identify technical constraints and integrations
• Produce Scope Brief document

ARTIFACTS

• Scope Brief: 1-2 page summary of client needs, constraints, and initial feature list
• Competitive context notes
• Client contact information

GATE: SCOPE_BRIEF_APPROVED

• Dima has enough information to hand off to Aimee
• No ambiguous requirements remain in the Scope Brief
• Client has confirmed the Scope Brief reflects their intent
• Feature list is categorized (MVP / Phase 2 / Future)

GATE_FAILURE_ACTIONS

• Dima schedules follow-up conversation with client
• Specific questions are prepared targeting the ambiguous areas
• Maximum 3 follow-up rounds before escalation to human (Dirk-Jan)

---

PHASE_2: CONTRACT

OWNER: eric (Contract + KYC) ZONE: PAYWALL DURATION: 1-2 business days

ACTIVITIES

• Generate contract from Scope Brief
• KYC verification for business clients
• Pricing calculation based on scope complexity
• Payment processing setup
• Legal terms acceptance

PRICING_MODEL

• Base: 10% of equivalent human developer cost
• Margin target: 5x token cost
• Hourly equivalent: EUR 25/hr (Dima chatbot rate for ongoing support)
• Project pricing: fixed price per scope, derived from WP count estimate

ARTIFACTS

• Signed contract
• Payment confirmation
• Client record in system

GATE: CONTRACT_SIGNED

• Contract signed by client
• First payment received (or payment method verified for subscription)
• KYC passed (if applicable)
• Client record created in database

---

PHASE_3: SCOPING

OWNER: aimee (Scope Architect, Opus model) ZONE: SHARED (serves all teams) DURATION: 1-3 hours agent time

ACTIVITIES

• Expand Scope Brief into full Functional Specification
• Feature decomposition into user stories
• Acceptance criteria writing for each feature
• Cross-cutting concern identification (auth, i18n, a11y, performance, SEO)
• Technology stack confirmation (TS/Next.js + Python/FastAPI from curated menu)
• Integration requirements mapping
• Scope negotiation with client (via Dima as relay, or direct)

ARTIFACTS

• Functional Specification document (10-30 pages depending on project size)
• Feature priority matrix (MoSCoW)
• Integration requirements document
• Non-functional requirements document
• Pricing inputs for Eric (final project cost)

GATE: FUNCTIONAL_SPEC_APPROVED

• Client has reviewed and approved functional spec
• All features have acceptance criteria
• Non-functional requirements defined (performance targets, uptime, data retention)
• Technology stack confirmed
• No scope creep — features match contract
• Aimee and client agree on what is in/out of scope

SCOPE_FREEZE

• After this gate, scope is frozen for the project
• New features require a change request (CR) process
• CRs go back to Aimee for impact assessment and repricing
• Minor clarifications (not new features) are handled by the PM

---

PHASE_4: SPECIFICATION

OWNER: anna (Formal Specification Agent) ZONE: SHARED DURATION: 1-2 hours agent time

ACTIVITIES

• Transform Aimee's functional spec into formal, unambiguous specification
• Define invariants and pre/post conditions
• Model state machines for complex workflows
• Specify API contracts (request/response schemas)
• Enumerate edge cases and error conditions
• Write requirement IDs (REQ-nnn) for traceability

ARTIFACTS

• Formal Specification document with requirement IDs
• State machine diagrams (Mermaid)
• API contract definitions (OpenAPI-compatible)
• Edge case matrix

GATE: FORMAL_SPEC_APPROVED

• Every functional requirement has a formal specification
• No ambiguous language remains ("should," "might," "usually" are banned)
• State machines cover all states and transitions
• API contracts are complete (all endpoints, all fields, all error codes)
• Edge cases are enumerated for every requirement
• PM (Faye/Sytske) confirms spec is decomposable into WPs

---

PHASE_5: DESIGN

OWNER: alexander (Design System Engineer) ZONE: SHARED DURATION: 30-90 minutes agent time

ACTIVITIES

• Create DESIGN.md from formal spec (see design-system-engineering.md)
• Select shadcn/ui components for each screen
• Define design tokens (colors, spacing, typography)
• Create responsive layout specifications
• Use Stitch MCP for custom screen generation (Layer 2, ~15% of screens)
• Accessibility review (color contrast, touch targets, motion)

ARTIFACTS

• DESIGN.md (machine-readable design specification)
• Component selection map (screen → components)
• Design token definitions
• Stitch-generated mockups (if Layer 2 screens exist)

GATE: DESIGN_APPROVED

• DESIGN.md covers all screens from formal spec
• All design tokens are defined
• Component selections are valid shadcn/ui components
• Accessibility requirements met (WCAG 2.1 AA)
• Client has seen representative mockups (Stitch output) and approved visual direction

---

PHASE_6: PLANNING

OWNER: faye (Team Alpha) or sytske (Team Beta) ZONE: TEAM DURATION: 30-60 minutes agent time

ACTIVITIES

• Decompose formal spec into Work Packages (see work-package-design.md)
• Build dependency graph (DAG)
• Identify critical path
• Assign swimming lanes and agents
• Set parallel execution groups
• Build traceability matrix (REQ → WP mapping)
• Estimate total project duration

ARTIFACTS

• Work Package set (YAML definitions)
• Dependency graph
• Traceability matrix
• Project schedule (critical path + parallel groups)
• Resource allocation plan (which agents, which phases)

GATE: WP_SET_APPROVED

• Every requirement has at least one WP
• Every WP has exactly one assignee
• Dependency graph has no cycles
• No WP exceeds 45 minutes estimated
• Critical path is identified
• Parallel execution groups are defined
• Traceability matrix shows 100% coverage

---

PHASE_7: DEVELOPMENT

OWNER: faye/sytske (monitoring), team agents (executing) ZONE: TEAM DURATION: varies (hours to days depending on project size)

ACTIVITIES

• PM submits WP set to orchestrator
• Orchestrator dispatches WPs respecting dependency DAG
• Agents execute WPs in their swimming lanes
• Antje's TDD specs guide implementation
• PM monitors progress via admin-ui dashboard
• PM handles blockers, re-plans when triggers fire

VELOCITY_TRACKING

• Track WPs completed per hour
• Track agent session cost per WP
• Compare actual vs estimated WP duration
• Flag WPs that exceed 150% of estimate

STATUS_REPORTING

## Daily Status: {project_code} — {date}

### Progress
- WPs completed today: {n} / {total}
- WPs in progress: {n}
- WPs blocked: {n}
- Critical path progress: {current_wp} / {critical_path_length}

### Velocity
- Average WP completion time: {minutes}
- Cost today: ${amount}
- Projected total cost: ${amount}

### Blockers
- {WP-nnn}: {blocker description} — action: {action}

### Tomorrow
- Expected completions: {WP list}
- Parallel group starting: {WP list}

REPLANNING_TRIGGERS

• WP fails twice → review scope, may split or reassign
• Agent discovers missing requirement → create ad-hoc WP
• Critical path blocked → look for unblocking alternatives
• Cost exceeding estimate by 50% → scope review with Aimee

GATE: ALL_WPS_COMPLETE

• All WPs in COMPLETE status
• No WPs in BLOCKED or FAILED status
• Antje's TDD specs pass
• Koen's lint check passes
• Traceability matrix shows 100% implemented

---

PHASE_8: INTEGRATION_TESTING

OWNER: marije (Test Execution), jasper (SSOT Reconciliation) ZONE: TEAM DURATION: 1-3 hours agent time

ACTIVITIES

• Marije runs integration test suite
• Cross-module interaction testing
• API endpoint integration with frontend
• Database integrity checks
• Auth flow end-to-end testing
• Jasper reconciles codebase against spec (SSOT check)
• Marco resolves any code conflicts from parallel WPs
• Ashley runs adversarial testing (security, edge cases)

ANTI_LLM_PIPELINE

Koen (linting) → Marije (test execution) → Jasper (SSOT reconcile) →
Marco (conflict resolution) → Ashley (adversarial) → Jaap (SSOT final) →
Marta (merge to main)

RULE: this pipeline runs in strict sequence. No skipping. RULE: any failure sends the project back to the failing agent for fixes, then restarts the pipeline from that point.

GATE: INTEGRATION_TESTS_PASS

• All integration tests green
• No lint errors
• SSOT reconciliation shows spec-code alignment
• No unresolved merge conflicts
• Adversarial tests pass (no security holes, no crash-on-edge-case)
• Code merged to main branch

---

PHASE_9: UAT

OWNER: faye/sytske (coordination), client (testing) ZONE: TEAM DURATION: 1-5 business days (client dependent)

ACTIVITIES

• Deploy to staging environment
• Provide client with staging URL and test accounts
• Client tests against acceptance criteria from functional spec
• PM tracks feedback and categorizes (bug vs enhancement vs out-of-scope)
• Bugs go back to development as priority WPs
• Enhancements are logged as change requests
• Out-of-scope items are documented for future phases

UAT_FEEDBACK_TEMPLATE

## UAT Feedback: {project_code}

### Item {n}
- Reporter: {client contact}
- Screen/Feature: {name}
- Description: {what happened}
- Expected: {what should happen}
- Category: BUG | ENHANCEMENT | OUT_OF_SCOPE
- Priority: CRITICAL | HIGH | MEDIUM | LOW
- Screenshot: {if available}

UAT_RULES

RULE: CRITICAL bugs block go-live. Must be fixed. RULE: HIGH bugs should be fixed before go-live. PM decides with client. RULE: MEDIUM/LOW bugs can be deferred to post-launch maintenance. RULE: ENHANCEMENTS are never addressed during UAT — they become change requests. RULE: UAT has a time-box. After agreed period, remaining non-critical items move to backlog.

GATE: CLIENT_SIGN_OFF

• Client confirms all CRITICAL and HIGH bugs are resolved
• Client signs off on the application matching the functional spec
• Deferred items are documented in backlog
• Client accepts the staging version for production deployment

---

PHASE_10: DEPLOYMENT

OWNER: jorrit (Infrastructure), faye/sytske (coordination) ZONE: TEAM DURATION: 1-4 hours

ACTIVITIES

• Production environment provisioning (k8s namespace, secrets, DNS)
• Database migration to production
• Application deployment
• SSL certificate provisioning
• Health check verification
• Performance baseline measurement
• Monitoring setup (uptime, error rates, response times)
• Rollback plan documented

DEPLOYMENT_CHECKLIST

PRE-DEPLOYMENT:
[ ] Production environment provisioned
[ ] Secrets configured (DB credentials, API keys, auth keys)
[ ] DNS records created
[ ] SSL certificates provisioned
[ ] Rollback plan documented
[ ] Monitoring alerts configured

DEPLOYMENT:
[ ] Database migration applied
[ ] Application containers deployed
[ ] Health checks passing
[ ] SSL working (HTTPS redirect)
[ ] API endpoints responding

POST-DEPLOYMENT:
[ ] Smoke test all critical paths (login, core feature, payment if applicable)
[ ] Performance within acceptable bounds
[ ] Error rate at baseline (< 0.1%)
[ ] Monitoring dashboard accessible
[ ] Client notified of production URL

GATE: PRODUCTION_HEALTHY

• Application is running and accessible at production URL
• Health checks passing for 30+ minutes
• No error spikes in monitoring
• Core user flows working (tested manually or via smoke tests)
• Client can log in and use the application

---

PHASE_11: HANDOFF

OWNER: faye/sytske (coordination), joost (documentation) ZONE: TEAM DURATION: 1-2 hours agent time

ACTIVITIES

• Generate operations documentation
• Document deployment procedure for future updates
• Document environment configuration
• Create runbook for common issues
• Hand off monitoring access to client (if self-managed)
• Set up maintenance agreement (if applicable)
• Archive project in GE systems

HANDOFF_ARTIFACTS

• Operations guide (deployment, monitoring, troubleshooting)
• Environment configuration document
• API documentation (auto-generated from OpenAPI spec)
• User guide (if applicable)
• Maintenance SLA (if ongoing support contracted)

GATE: HANDOFF_COMPLETE

• All documentation delivered
• Client confirms they have access to everything they need
• Maintenance agreement signed (if applicable)
• Project archived in GE system
• PM closes project in admin-ui

---

MILESTONE_SUMMARY

| Phase          | Owner           | Duration      | Gate                        |
|----------------|-----------------|---------------|-----------------------------|
| 1. Intake      | Dima            | 15-30 min     | Scope Brief Approved        |
| 2. Contract    | Eric            | 1-2 days      | Contract Signed             |
| 3. Scoping     | Aimee           | 1-3 hrs       | Functional Spec Approved    |
| 4. Specification | Anna          | 1-2 hrs       | Formal Spec Approved        |
| 5. Design      | Alexander       | 30-90 min     | DESIGN.md Approved          |
| 6. Planning    | Faye/Sytske     | 30-60 min     | WP Set Approved             |
| 7. Development | Team            | Hours-Days    | All WPs Complete            |
| 8. Integration | Marije+Pipeline | 1-3 hrs       | Integration Tests Pass      |
| 9. UAT         | Client          | 1-5 days      | Client Sign-off             |
| 10. Deployment | Jorrit          | 1-4 hrs       | Production Healthy          |
| 11. Handoff    | Joost           | 1-2 hrs       | Handoff Complete            |

TYPICAL_SMALL_PROJECT: 3-5 business days end-to-end TYPICAL_MEDIUM_PROJECT: 1-2 weeks end-to-end TYPICAL_LARGE_PROJECT: 2-4 weeks end-to-end

---

SCOPE_CHANGE_MANAGEMENT

CHANGE_REQUEST_PROCESS

STEP_1: client raises change (via Dima or directly to PM) STEP_2: PM categorizes: clarification (free) vs new scope (CR required) STEP_3: if CR: PM sends to Aimee for impact assessment STEP_4: Aimee produces delta spec and cost estimate STEP_5: Eric generates amended contract with new pricing STEP_6: client approves or defers STEP_7: if approved: Anna updates formal spec, PM creates new WPs, development resumes

SCOPE_CREEP_DEFENSE

RULE: "can you also add..." is always a CR, never a quick fix. RULE: PM never says "yes" to new scope without Aimee's impact assessment. RULE: the functional spec is the contract. If it is not in the spec, it is not in scope. RULE: client-facing communication always references the spec: "Per section 3.2 of the functional specification..."

---

PROJECT_HEALTH_INDICATORS

GREEN: on schedule, on budget, no blockers, gates passing
YELLOW: 1 day behind, or 120% of budget, or 1 persistent blocker
RED: 2+ days behind, or 150% of budget, or critical path blocked
BLACK: client relationship at risk, or project viability in question

ESCALATION: - GREEN: no action needed - YELLOW: PM adjusts plan, reports to team lead - RED: PM escalates to mira (monitoring), seeks human input - BLACK: immediate escalation to Dirk-Jan

---

VELOCITY_BENCHMARKS

Based on GE operational data:

| Metric                          | Target    | Alert     |
|---------------------------------|-----------|-----------|
| WPs completed per agent-hour    | 2-3       | < 1       |
| Average WP duration             | 25 min    | > 45 min  |
| WP first-attempt success rate   | > 85%     | < 70%     |
| Agent session cost per WP       | $0.50-2   | > $4      |
| Critical path slip per phase    | 0 days    | > 1 day   |
| Integration test pass rate      | > 95%     | < 80%     |