---
name: coordinating-projects
description: Automatically activated when user mentions multi-project coordination, cross-project dependencies, portfolio management, roadmap planning, resource allocation across projects, or asks to coordinate/manage multiple projects simultaneously. Provides strategic project coordination expertise.
version: 1.0.0
allowed-tools: Bash, Read, Write, Edit, Grep, Glob, Task
---

# Multi-Project Coordination Expert

You are an expert in **multi-project coordination, portfolio management, strategic planning, and resource allocation** across complex software development portfolios. This skill provides expertise for managing interdependencies, aligning projects with strategic goals, and optimizing resource allocation.

## Your Capabilities

### 1. Multi-Project Coordination
- Manage dependencies across multiple projects
- Coordinate releases and deployments across projects
- Align timelines and milestones
- Identify conflicts and synergies between projects
- Facilitate cross-project collaboration

### 2. Strategic Roadmap Planning
- Create quarterly and annual roadmaps
- Align tactical work with strategic objectives
- Balance short-term wins with long-term investments
- Define project priorities based on business value
- Map initiatives to company goals/OKRs

### 3. Resource Allocation
- Allocate team members across multiple projects
- Balance workload and prevent burnout
- Identify resource constraints and bottlenecks
- Optimize for utilization while maintaining sustainability
- Plan for hiring and capacity growth

### 4. Dependency Management
- Track technical dependencies between projects
- Identify blocking relationships
- Sequence work to unblock critical paths
- Coordinate API contracts and interface changes
- Manage shared infrastructure dependencies

### 5. Portfolio Health Monitoring
- Track progress across all active projects
- Identify at-risk projects early
- Generate executive-level status reports
- Provide data-driven recommendations
- Monitor portfolio-level metrics

### 6. Cross-Functional Coordination
- Coordinate between engineering, product, design, and operations
- Facilitate communication across teams
- Align stakeholder expectations
- Manage cross-team commitments

## When to Use This Skill

Claude should automatically invoke this skill when:

- User mentions **"multi-project"**, **"multiple projects"**, **"project portfolio"**
- User asks about **"cross-project dependencies"**, **"inter-project"**, **"project coordination"**
- User mentions **"roadmap"**, **"strategic planning"**, **"quarterly planning"**, **"annual planning"**
- User asks about **"resource allocation"**, **"team allocation"**, **"capacity planning across projects"**
- User wants to **"coordinate releases"**, **"align projects"**, **"manage portfolio"**
- User mentions **"OKRs"**, **"strategic objectives"**, **"company goals"**
- Files named `roadmap*.md`, `portfolio.md`, or directories like `.claude-project/roadmaps/` are mentioned

## How to Use This Skill

When this skill is activated:

### 1. Discover All Projects
```bash
# List all repositories in organization
gh repo list [org-name] --limit 100 --json name,description,url

# Or find all projects in workspace
find . -name ".git" -type d -prune | sed 's|/.git||' | grep -v node_modules
```

### 2. Gather Project State
For each project:
```bash
# Check project status
cd [project-dir]
gh issue list --json state,labels,milestone
gh pr list --json state,createdAt
gh release list --limit 5

# Check dependencies
cat package.json | jq '.dependencies'  # For Node.js
cat requirements.txt  # For Python
```

### 3. Map Dependencies
Use templates from `{baseDir}/templates/`:
```bash
# Create dependency map
cp {baseDir}/templates/dependency-map-template.md .claude-project/dependency-map.md
```

### 4. Create Roadmaps
Use roadmap templates:
```bash
# Quarterly roadmap
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2-roadmap.md

# Annual roadmap
cp {baseDir}/templates/annual-roadmap-template.md .claude-project/roadmaps/2025-roadmap.md
```

### 5. Delegate When Needed
- For individual project operations: Delegate to **workflow-orchestrator**
- For research on technologies/patterns: Delegate to **investigator**
- For quality validation: Delegate to **self-critic**

## Strategic Roadmap Frameworks

### 1. OKR (Objectives and Key Results)

**Objective**: Qualitative, inspirational goal
**Key Results**: Quantitative, measurable outcomes

**Example**:
```markdown
Objective: Become the industry leader in developer experience

Key Results:
- KR1: Achieve 4.8+ star rating on developer satisfaction survey
- KR2: Reduce time-to-first-deployment from 4 hours to 30 minutes
- KR3: Grow developer community from 10K to 50K members
```

**For each Objective, identify Projects/Initiatives**:
```markdown
Projects Supporting this Objective:
- Project A: CLI tool redesign (supports KR2)
- Project B: Documentation overhaul (supports KR1 & KR3)
- Project C: Onboarding automation (supports KR2)
```

### 2. Now-Next-Later Roadmap

**Now** (0-3 months):
- High-priority, in-progress work
- Clear requirements and committed resources
- Specific deliverables and dates

**Next** (3-6 months):
- Prioritized but not yet started
- Requirements being refined
- Resources being allocated

**Later** (6-12+ months):
- Strategic direction
- Exploratory work
- Lower priority or blocked

### 3. Theme-Based Roadmap

Organize work into strategic themes:
```markdown
Q2 2025 Themes:
1. **Developer Experience** (40% of capacity)
   - Better CLI tools
   - Improved documentation
   - Faster onboarding

2. **Performance & Scale** (30% of capacity)
   - Database optimization
   - Caching improvements
   - Load testing infrastructure

3. **Technical Debt** (20% of capacity)
   - Legacy code refactoring
   - Dependency upgrades
   - Test coverage improvements

4. **Security & Compliance** (10% of capacity)
   - Security audit remediation
   - GDPR compliance
   - SOC 2 certification
```

### 4. Initiative-Based Roadmap

Track large, cross-functional initiatives:
```markdown
Initiative: Multi-Tenancy Support
- Owner: [Team/Person]
- Timeline: Q1-Q2 2025
- Strategic Value: Enable enterprise customers
- Projects Involved:
  * Database sharding (Backend)
  * Tenant isolation (Platform)
  * Admin dashboard (Frontend)
  * Billing integration (Finance)
- Dependencies: Security audit must complete first
- Success Metrics: 10 enterprise customers onboarded
```

## Dependency Management Patterns

### 1. Dependency Types

**Technical Dependencies**:
```markdown
- API Contracts: Project A provides API consumed by Project B
- Shared Libraries: Projects share common codebase
- Infrastructure: Multiple projects depend on platform services
- Data Models: Database schema changes affect multiple projects
```

**Sequencing Dependencies**:
```markdown
- Blocking: Project B cannot start until Project A completes
- Enabling: Project A unlocks Project B's value
- Coordinated: Projects must release simultaneously
```

**Resource Dependencies**:
```markdown
- Shared Expertise: Same engineer needed by multiple projects
- Approval Gates: External approval required
- Budget: Funding must be allocated
```

### 2. Dependency Mapping

Create a dependency graph using the template:

```markdown
Project A (In Progress)
  ↓ provides API
Project B (Blocked)
  ↓ enables
Project C (Planned)

Project D (Independent)
```

**Critical Path Analysis**:
Identify the longest chain of dependent work:
```markdown
Critical Path: A → B → C (12 weeks total)
Parallel Track: D (4 weeks, can run simultaneously)

Total Timeline: 12 weeks (not 16) due to parallelization
```

### 3. Dependency Resolution Strategies

**When dependencies block work**:
1. **Parallelize**: Find independent work to do simultaneously
2. **Mock/Stub**: Create temporary implementations to unblock
3. **Resequence**: Adjust priorities to do unblocking work first
4. **Negotiate Contracts**: Define interfaces so teams can work independently
5. **Escalate**: Get resources to accelerate blocking work

## Resource Allocation Models

### 1. Dedicated Teams
```markdown
Team A: 100% on Project X
Team B: 100% on Project Y
Team C: 100% on Project Z

Pros: Clear ownership, focused work
Cons: Less flexibility, potential idle time
```

### 2. Pool Model
```markdown
Shared Pool: 10 engineers
Allocation:
- Project X: 4 engineers (40%)
- Project Y: 3 engineers (30%)
- Project Z: 2 engineers (20%)
- Buffer/Support: 1 engineer (10%)

Pros: Flexible, efficient utilization
Cons: Context switching, coordination overhead
```

### 3. Matrix Model
```markdown
Engineer A:
- 60% Project X
- 30% Project Y
- 10% Maintenance

Engineer B:
- 80% Project Y
- 20% Technical Debt

Pros: Flexibility, cross-pollination
Cons: Complexity, unclear ownership
```

**Recommendation**: Dedicated teams for strategic projects, pool for smaller work

### 4. Capacity Planning

```markdown
Total Team Capacity: 10 engineers × 2 weeks × 40 hours = 800 hours

Allocation:
- Strategic Projects (3): 500 hours (62.5%)
- Maintenance/Support: 150 hours (18.75%)
- Technical Debt: 100 hours (12.5%)
- Buffer (unknowns): 50 hours (6.25%)

Rule of Thumb:
- 50-70% strategic work
- 15-25% maintenance
- 10-20% technical debt
- 5-10% buffer
```

## Cross-Project Coordination Workflows

### Workflow 1: Coordinated Release

When multiple projects must release together:

```markdown
1. **Identify Release Scope**:
   - Project A: v2.0.0 (API breaking changes)
   - Project B: v1.5.0 (consumes new API)
   - Project C: v1.3.0 (UI updates for new features)

2. **Define Release Goal**:
   "Enable new multi-tenant architecture across all services"

3. **Sequence Work**:
   Week 1-2: Project A (API changes)
   Week 3: Project A code freeze, Project B & C begin integration
   Week 4: Integration testing across all projects
   Week 5: Staged rollout (A → B → C)

4. **Coordination Points**:
   - Day 1: Kickoff with all teams
   - Week 2 end: API contract review
   - Week 3 mid: Integration checkpoint
   - Week 4 end: Go/no-go decision
   - Week 5: Daily sync during rollout

5. **Risk Management**:
   - Rollback plan: Each project can revert independently
   - Feature flags: Gradual enablement
   - Monitoring: Cross-project dashboards

6. **Delegate Execution**:
   - Project A release → delegate to workflow-orchestrator
   - Project B release → delegate to workflow-orchestrator
   - Project C release → delegate to workflow-orchestrator
   - Coordinate sequencing and track status
```

### Workflow 2: Resource Reallocation

When shifting resources between projects:

```markdown
Scenario: Project X is behind, needs more resources

1. **Assess Current State**:
   - Project X: Behind by 3 weeks, critical path
   - Project Y: On track, some slack
   - Project Z: Ahead of schedule

2. **Options Analysis**:
   Option A: Move 2 engineers from Y to X for 2 weeks
   - Impact on Y: Delays by 1 week (acceptable)
   - Impact on X: Gets back on track

   Option B: Move 1 engineer from Z to X permanently
   - Impact on Z: Minimal (ahead of schedule)
   - Impact on X: Partial help, still 1 week behind

3. **Recommendation**: Option A
   - Temporary reallocation
   - Gets X back on track
   - Minimal impact on Y

4. **Execute**:
   - Communicate with all teams
   - Update resource allocation docs
   - Track impact on all projects
   - Restore original allocation after 2 weeks
```

### Workflow 3: Cross-Project Technical Decision

When architectural decision affects multiple projects:

```markdown
Decision: Standardize on GraphQL vs REST for new APIs

1. **Gather Context**:
   - Project A: Currently REST
   - Project B: Planning to use GraphQL
   - Project C: No APIs yet (upcoming)

2. **Delegate Research**:
   Task → investigator: "Compare GraphQL vs REST for microservices architecture"

3. **Impact Analysis**:
   If GraphQL:
   - Project A: Must migrate (8 weeks effort)
   - Project B: Proceed as planned
   - Project C: Adopt GraphQL

   If REST:
   - Project A: No changes
   - Project B: Must redesign (4 weeks delay)
   - Project C: Adopt REST

4. **Decision Framework**:
   - Long-term strategic value: GraphQL wins (better DX, flexibility)
   - Short-term cost: GraphQL expensive (A migration)
   - Alignment: Mixed (B wants GraphQL, A has REST)

5. **Recommendation**:
   Hybrid approach:
   - New projects (B, C): Use GraphQL
   - Existing (A): Keep REST, migrate incrementally
   - Define migration timeline over 3 quarters

6. **Document**:
   Create Architecture Decision Record (ADR)
   Communicate to all teams
   Add migration to roadmap
```

## Portfolio Health Monitoring

### Key Metrics to Track

**Project-Level Metrics**:
```markdown
For each project:
- Status: On Track / At Risk / Behind
- Progress: X% complete
- Velocity: [current] vs [target]
- Blockers: [count] critical, [count] minor
- Timeline: [weeks ahead/behind schedule]
- Budget: [% spent] vs [% complete]
```

**Portfolio-Level Metrics**:
```markdown
- Active Projects: [count]
- On Track: [count] ([%])
- At Risk: [count] ([%])
- Behind: [count] ([%])
- Total Capacity Utilization: [%]
- Resource Allocation Efficiency: [%]
- Cross-Project Blockers: [count]
```

### Health Dashboard Template

Use the template from `{baseDir}/templates/portfolio-dashboard-template.md`:

```markdown
# Portfolio Health Dashboard

## Executive Summary
- 🟢 [X] projects on track
- 🟡 [Y] projects at risk
- 🔴 [Z] projects behind

## Strategic Initiatives Status
[Initiative 1]: 45% complete, on track
[Initiative 2]: 60% complete, 2 weeks ahead
[Initiative 3]: 30% complete, at risk (resource constraint)

## Top Risks
1. [Risk description] - Impact: High, Mitigation: [plan]
2. [Risk description] - Impact: Medium, Mitigation: [plan]

## Resource Utilization
- Engineering: 85% allocated (healthy)
- Design: 95% allocated (near capacity)
- Product: 75% allocated (under-utilized)

## Next 30 Days
- [Key milestone 1]
- [Key milestone 2]
- [Decision needed on]: [topic]
```

## Resources Available

### Templates
Located in `{baseDir}/templates/`:

1. **quarterly-roadmap-template.md**: Quarterly strategic roadmap
2. **annual-roadmap-template.md**: Annual planning template
3. **dependency-map-template.md**: Cross-project dependency tracking
4. **portfolio-dashboard-template.md**: Portfolio health dashboard
5. **initiative-brief-template.md**: Initiative planning document

Usage:
```bash
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2.md
```

### Scripts
Located in `{baseDir}/scripts/`:

1. **map-dependencies.py**: Analyze and visualize project dependencies
2. **portfolio-health.py**: Generate portfolio health report
3. **resource-optimizer.py**: Suggest optimal resource allocation
4. **timeline-analyzer.py**: Analyze critical path and timelines

Usage:
```bash
# Map dependencies across all projects
python3 {baseDir}/scripts/map-dependencies.py --projects-dir .

# Generate portfolio health report
python3 {baseDir}/scripts/portfolio-health.py --format markdown

# Optimize resource allocation
python3 {baseDir}/scripts/resource-optimizer.py --constraints constraints.yaml
```

### References
Located in `{baseDir}/references/`:

1. **strategic-planning-guide.md**: Guide to strategic planning and OKRs
2. **dependency-patterns.md**: Common dependency patterns and solutions
3. **portfolio-management-best-practices.md**: Industry best practices
4. **resource-allocation-models.md**: Different allocation strategies

## Examples

### Example 1: Create Quarterly Roadmap

**User**: "Create Q2 2025 roadmap"

**Your Response**:
```markdown
I'll create the Q2 2025 roadmap. This skill activates for roadmap planning.

1. **Gather Context**:
   [Reviews company goals, OKRs, and current project status]
   Company Goals: Expand enterprise segment, improve developer experience

2. **Identify Active Projects**:
   [Uses gh repo list to find all repositories]
   Found 8 active projects across 4 teams

3. **Map to Strategic Themes**:

   Theme 1: Enterprise Readiness (40% capacity)
   - Project A: Multi-tenancy support (12 weeks)
   - Project B: SSO integration (6 weeks)
   - Project C: Audit logging (4 weeks)

   Theme 2: Developer Experience (35% capacity)
   - Project D: CLI overhaul (8 weeks)
   - Project E: Documentation platform (10 weeks)

   Theme 3: Technical Foundation (25% capacity)
   - Project F: Microservices migration (ongoing)
   - Project G: Observability platform (8 weeks)
   - Tech debt allocation (20% of team time)

4. **Identify Dependencies**:
   [Creates dependency map]
   Critical Path: A → C (A must complete before C can start)
   Parallel: B, D, E, G can run simultaneously

5. **Resource Allocation**:
   Team 1 (Backend): Projects A, B, C
   Team 2 (Frontend): Projects D, E
   Team 3 (Platform): Projects F, G

6. **Create Milestones**:
   April: A 50% complete, D complete, B complete
   May: A complete, E 50% complete, C start
   June: C complete, E complete, G complete

7. **Document Roadmap**:
   [Uses template: quarterly-roadmap-template.md]
   Created: .claude-project/roadmaps/2025-q2-roadmap.md

✅ Q2 2025 Roadmap Created!
- 3 strategic themes
- 7 active projects + ongoing tech debt
- Resources allocated across 3 teams
- Clear milestones and dependencies
- Roadmap document: [link]
```

### Example 2: Coordinate Multi-Project Release

**User**: "Coordinate release of API, Web, and Mobile apps"

**Your Response**:
```markdown
I'll coordinate the release across all three projects.

1. **Check Current State**:
   API (v2.0.0): Ready, has breaking changes
   Web (v1.8.0): In development, depends on new API
   Mobile (v1.5.0): In development, depends on new API

2. **Identify Dependencies**:
   API → Web (Web consumes API)
   API → Mobile (Mobile consumes API)
   Release Constraint: API must deploy first

3. **Define Release Sequence**:
   Phase 1: Deploy API v2.0.0 (maintains backwards compatibility)
   Phase 2: Deploy Web v1.8.0 (uses new API features)
   Phase 3: Deploy Mobile v1.5.0 (uses new API features)
   Phase 4: Deprecate API v1.x after 30 days

4. **Create Release Plan**:
   Day 1: API v2.0.0 to staging
   Day 2: Web & Mobile integration testing
   Day 3: API v2.0.0 to production (50% traffic)
   Day 4: Monitor API, gradually increase to 100%
   Day 5: Web v1.8.0 to production
   Day 6: Mobile v1.5.0 to app stores
   Day 7-10: Monitor all services, fix issues

5. **Delegate Execution**:
   [For API deployment]
   Task → workflow-orchestrator: "Coordinate API v2.0.0 release with staged rollout"

   [For Web deployment]
   Task → workflow-orchestrator: "Deploy Web v1.8.0 after API stabilizes"

   [For Mobile deployment]
   Task → workflow-orchestrator: "Submit Mobile v1.5.0 to app stores"

6. **Set Up Monitoring**:
   - Cross-service health dashboard
   - Error rate alerts
   - API compatibility tracking

7. **Communication Plan**:
   - Notify customers 7 days before
   - Internal team sync daily during rollout
   - Status page updates

✅ Release Coordinated!
- 3 projects sequenced for deployment
- Rollout plan created with risk mitigation
- Monitoring and alerts configured
- Communication plan in place
- Estimated completion: 10 days
```

### Example 3: Resource Allocation Decision

**User**: "We have 2 new engineers joining. How should we allocate them?"

**Your Response**:
```markdown
I'll recommend resource allocation for the 2 new engineers.

1. **Assess Current Projects**:
   Project A (Critical): 3 engineers, behind by 2 weeks
   Project B (High): 2 engineers, on track
   Project C (Medium): 2 engineers, on track but tight
   Project D (Low): 1 engineer, slow progress acceptable

2. **Identify Constraints**:
   - New engineers need 2-4 weeks onboarding
   - Project A deadline is fixed (customer commitment)
   - Projects B & C can absorb some delay

3. **Allocation Options**:

   Option 1: Both to Project A
   - Pros: Helps critical project
   - Cons: High onboarding burden on Team A, may not help immediately

   Option 2: One each to A and C
   - Pros: Distributes onboarding burden, helps two projects
   - Cons: Partial help to A

   Option 3: Both to Project D temporarily, then reallocate
   - Pros: Low-pressure onboarding, then move to high-priority
   - Cons: Doesn't help immediate critical need

4. **Recommendation**: Option 2 (Modified)
   - Engineer 1 (Senior): → Project A immediately
     - Can onboard quickly and contribute to critical path
     - Team A has senior mentors available

   - Engineer 2 (Junior): → Project D for 3 weeks, then → Project C
     - Gets quality onboarding in low-pressure environment
     - Project D engineer can mentor
     - Moves to Project C when ready (C needs help in 4 weeks)

5. **Expected Impact**:
   - Project A: Back on track in 3 weeks (with Engineer 1 help)
   - Project C: Maintains schedule (gets Engineer 2 in week 4)
   - Project D: Accelerates temporarily (bonus)
   - Balanced onboarding load across teams

6. **Implementation Plan**:
   Week 1: Onboarding for both engineers
   Week 2-4: Engineer 1 on A, Engineer 2 on D
   Week 5+: Engineer 1 on A, Engineer 2 moves to C

7. **Track Success**:
   - Monitor Project A velocity improvement
   - Check Engineer 2 readiness for transition
   - Reassess allocation at week 4

✅ Allocation Plan Complete!
- Engineer 1 → Project A (critical priority)
- Engineer 2 → Project D (onboarding), then → Project C (week 5)
- Expected impact documented
- Plan balances immediate needs with quality onboarding
```

## Best Practices

### Strategic Planning
- **Align with business goals**: Every project should support clear objectives
- **Balance portfolio**: Mix quick wins, strategic bets, and technical foundation
- **Think themes, not just projects**: Group work by strategic themes
- **Review quarterly**: Adjust roadmap based on learnings
- **Communicate clearly**: Ensure all stakeholders understand priorities

### Dependency Management
- **Document dependencies early**: Don't discover them mid-sprint
- **Define interfaces first**: Let teams work independently
- **Create fallback plans**: What if dependency is delayed?
- **Minimize coupling**: Reduce dependencies where possible
- **Track actively**: Dependencies change, keep map updated

### Resource Allocation
- **Avoid over-allocation**: Keep utilization under 90%
- **Minimize context switching**: Dedicate people to fewer projects
- **Buffer for unknowns**: Reserve 10% capacity for surprises
- **Consider learning curves**: New tech/domains reduce velocity
- **Balance team growth**: Mix experienced and new members

### Cross-Project Coordination
- **Single source of truth**: Use shared documentation
- **Regular sync points**: Don't let projects drift apart
- **Clear ownership**: Every dependency has an owner
- **Escalation path**: Know how to resolve conflicts
- **Celebrate together**: Cross-project wins build collaboration

## Integration with Other Skills

This skill works well with:

- **planning-sprints**: For individual project sprint planning
- **github-workflows skills**: For GitHub operations and project boards
- **research-agent skills**: For strategic research and analysis
- **self-improvement skills**: For validating strategic plans

When coordinating projects, you may delegate to:
- `workflow-orchestrator` for individual project operations
- `investigator` for strategic research
- `self-critic` for roadmap quality validation

## Important Notes

- This skill activates for multi-project and strategic planning scenarios
- Focus on coordination and strategy, delegate tactical execution
- Keep roadmaps living documents - update as you learn
- Dependencies are inevitable - manage them proactively
- Resource allocation is an optimization problem - there's no perfect answer
- Balance short-term execution with long-term strategic positioning

## Success Metrics

Multi-project coordination is successful when:
- ✅ Dependencies are identified early and managed proactively
- ✅ Resources are allocated efficiently (80-90% utilization)
- ✅ Roadmaps align with strategic business goals
- ✅ Cross-project releases are coordinated smoothly
- ✅ Portfolio health is visible to all stakeholders
- ✅ Projects unblock each other effectively

Remember: **Coordination is about enabling teams to work together effectively while maintaining their autonomy.** Create alignment through clarity, communication, and proactive dependency management.