| 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
gh repo list [org-name] --limit 100 --json name,description,url
find . -name ".git" -type d -prune | sed 's|/.git||' | grep -v node_modules
2. Gather Project State
For each project:
cd [project-dir]
gh issue list --json state,labels,milestone
gh pr list --json state,createdAt
gh release list --limit 5
cat package.json | jq '.dependencies'
cat requirements.txt
3. Map Dependencies
Use templates from {baseDir}/templates/:
cp {baseDir}/templates/dependency-map-template.md .claude-project/dependency-map.md
4. Create Roadmaps
Use roadmap templates:
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2-roadmap.md
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:
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:
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:
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:
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:
- 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:
- Blocking: Project B cannot start until Project A completes
- Enabling: Project A unlocks Project B's value
- Coordinated: Projects must release simultaneously
Resource Dependencies:
- 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:
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:
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:
- Parallelize: Find independent work to do simultaneously
- Mock/Stub: Create temporary implementations to unblock
- Resequence: Adjust priorities to do unblocking work first
- Negotiate Contracts: Define interfaces so teams can work independently
- Escalate: Get resources to accelerate blocking work
Resource Allocation Models
1. Dedicated Teams
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
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
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
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:
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:
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:
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:
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:
- 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:
# 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/:
- quarterly-roadmap-template.md: Quarterly strategic roadmap
- annual-roadmap-template.md: Annual planning template
- dependency-map-template.md: Cross-project dependency tracking
- portfolio-dashboard-template.md: Portfolio health dashboard
- initiative-brief-template.md: Initiative planning document
Usage:
cp {baseDir}/templates/quarterly-roadmap-template.md .claude-project/roadmaps/2025-q2.md
Scripts
Located in {baseDir}/scripts/:
- map-dependencies.py: Analyze and visualize project dependencies
- portfolio-health.py: Generate portfolio health report
- resource-optimizer.py: Suggest optimal resource allocation
- timeline-analyzer.py: Analyze critical path and timelines
Usage:
python3 {baseDir}/scripts/map-dependencies.py --projects-dir .
python3 {baseDir}/scripts/portfolio-health.py --format markdown
python3 {baseDir}/scripts/resource-optimizer.py --constraints constraints.yaml
References
Located in {baseDir}/references/:
- strategic-planning-guide.md: Guide to strategic planning and OKRs
- dependency-patterns.md: Common dependency patterns and solutions
- portfolio-management-best-practices.md: Industry best practices
- resource-allocation-models.md: Different allocation strategies
Examples
Example 1: Create Quarterly Roadmap
User: "Create Q2 2025 roadmap"
Your Response:
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:
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:
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 operationsinvestigator for strategic researchself-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.
