agentic-team-templates 0.19.1 → 0.20.0

package/templates/business/project-manager/CLAUDE.md

@@ -0,0 +1,540 @@
+# Project Management Development Guide
+
+Principal-level guidelines for managing projects from initiation through closure, with emphasis on scope control, risk management, stakeholder alignment, and disciplined execution.
+
+---
+
+## Overview
+
+This guide applies to:
+
+- Project initiation and charter development
+- Work Breakdown Structure (WBS) creation
+- Schedule and timeline planning
+- Risk identification and management
+- Status reporting and dashboards
+- Stakeholder communication and RACI matrices
+- Change management and scope control
+- Lessons learned and project closure
+
+### Key Principles
+
+1. **Plan the Work, Work the Plan** - Rigorous upfront planning prevents costly downstream changes
+2. **Scope Discipline** - Every addition has a cost; guard the baseline relentlessly
+3. **Risk Forward** - Identify and mitigate risks before they become issues
+4. **Transparent Reporting** - Bad news early is better than bad news late
+5. **Stakeholder Alignment** - Misaligned expectations are the root of most project failures
+
+### Core Frameworks
+
+| Framework | Purpose |
+|-----------|---------|
+| WBS | Decompose deliverables into manageable work packages |
+| Critical Path Method | Identify the longest sequence of dependent tasks |
+| RAID Log | Track Risks, Assumptions, Issues, Dependencies |
+| RACI Matrix | Clarify roles and responsibilities |
+| Earned Value Management | Measure project performance objectively |
+| Change Control | Govern scope modifications formally |
+
+---
+
+## Project Initiation
+
+### Project Charter Template
+
+```markdown
+# Project Charter: [Project Name]
+
+## Project Overview
+- **Sponsor**: [Name, Title]
+- **Project Manager**: [Name]
+- **Date**: [Date]
+- **Version**: [1.0]
+
+## Business Case
+[2-3 sentences: Why is this project being undertaken? What business problem does it solve?]
+
+## Objectives
+1. [Specific, measurable objective 1]
+2. [Specific, measurable objective 2]
+3. [Specific, measurable objective 3]
+
+## Scope Summary
+### In Scope
+- [Deliverable 1]
+- [Deliverable 2]
+
+### Out of Scope
+- [Explicitly excluded item 1]
+- [Explicitly excluded item 2]
+
+## Key Stakeholders
+| Name | Role | Interest Level | Influence Level |
+|------|------|----------------|-----------------|
+| [Name] | Sponsor | High | High |
+| [Name] | End User | High | Medium |
+
+## High-Level Timeline
+| Milestone | Target Date |
+|-----------|-------------|
+| Project Kickoff | [Date] |
+| Phase 1 Complete | [Date] |
+| Final Delivery | [Date] |
+
+## Budget
+- Estimated budget: [$X]
+- Funding source: [Source]
+- Contingency: [X%]
+
+## Success Criteria
+1. [Criterion 1 - measurable]
+2. [Criterion 2 - measurable]
+
+## Assumptions
+1. [Assumption 1]
+2. [Assumption 2]
+
+## Constraints
+1. [Constraint 1]
+2. [Constraint 2]
+
+## Approval
+| Name | Role | Signature | Date |
+|------|------|-----------|------|
+| [Name] | Sponsor | | |
+| [Name] | PM | | |
+```
+
+---
+
+## Work Breakdown Structure (WBS)
+
+### WBS Decomposition Approach
+
+```
+Project Name (Level 0)
+├── Phase 1: Initiation (Level 1)
+│   ├── 1.1 Project Charter (Level 2)
+│   │   ├── 1.1.1 Draft charter (Level 3 - Work Package)
+│   │   ├── 1.1.2 Review with sponsor
+│   │   └── 1.1.3 Obtain approval
+│   └── 1.2 Stakeholder Analysis
+│       ├── 1.2.1 Identify stakeholders
+│       └── 1.2.2 Create communication plan
+├── Phase 2: Planning (Level 1)
+│   ├── 2.1 Requirements Gathering
+│   ├── 2.2 Schedule Development
+│   └── 2.3 Risk Planning
+├── Phase 3: Execution (Level 1)
+│   ├── 3.1 Deliverable 1
+│   ├── 3.2 Deliverable 2
+│   └── 3.3 Deliverable 3
+├── Phase 4: Monitoring & Control (Level 1)
+│   ├── 4.1 Status Reporting
+│   └── 4.2 Change Management
+└── Phase 5: Closure (Level 1)
+    ├── 5.1 Final Acceptance
+    └── 5.2 Lessons Learned
+```
+
+### WBS Best Practices
+
+- **100% Rule**: WBS must capture 100% of project scope, including project management
+- **Decompose to work packages**: Lowest level should be estimable (8-80 hour rule)
+- **Deliverable-oriented**: Organize by deliverables, not activities
+- **Mutually exclusive**: No overlap between branches
+- **WBS Dictionary**: Each work package gets a description, owner, estimate, and acceptance criteria
+
+### WBS Dictionary Entry
+
+```markdown
+## WBS Element: [1.2.3 Element Name]
+
+- **Description**: [What this work package produces]
+- **Owner**: [Responsible person]
+- **Effort Estimate**: [Hours/days]
+- **Duration**: [Calendar time]
+- **Dependencies**: [Predecessor WBS elements]
+- **Acceptance Criteria**: [How we know it is complete]
+- **Risks**: [Associated risks]
+```
+
+---
+
+## Schedule Planning
+
+### Task Dependencies
+
+| Type | Code | Example |
+|------|------|---------|
+| Finish-to-Start | FS | Design must finish before development starts |
+| Start-to-Start | SS | Testing starts when development starts |
+| Finish-to-Finish | FF | Documentation finishes when development finishes |
+| Start-to-Finish | SF | New system starts before old system finishes (rare) |
+
+### Critical Path Method
+
+```
+Task A (5d) ──→ Task C (3d) ──→ Task E (4d) ──→ Task G (2d)
+                                                        │
+Task B (3d) ──→ Task D (6d) ──→ Task F (2d) ──────────┘
+
+Critical Path: B → D → F → G = 13 days (longest path)
+Non-Critical: A → C → E → G = 14 days (actually this is critical)
+
+Float for Task B path: 14 - 13 = 1 day
+```
+
+### Milestone Planning Template
+
+| Milestone | Target Date | Dependencies | Owner | Status |
+|-----------|-------------|--------------|-------|--------|
+| Requirements Approved | [Date] | Stakeholder sign-off | PM | Not Started |
+| Design Complete | [Date] | Requirements Approved | Lead Designer | Not Started |
+| Development Complete | [Date] | Design Complete | Tech Lead | Not Started |
+| UAT Complete | [Date] | Development Complete | QA Lead | Not Started |
+| Go-Live | [Date] | UAT Complete | PM | Not Started |
+
+### Buffer Management
+
+- **Project buffer**: 10-20% of total duration at the end of the project
+- **Feeding buffers**: 50% of non-critical path duration where it joins critical path
+- **Resource buffers**: Alert resource managers before critical-path tasks start
+
+### Resource Leveling Checklist
+
+1. Identify resource over-allocations
+2. Delay non-critical tasks within float
+3. Split tasks where possible
+4. Adjust task assignments
+5. Negotiate additional resources if critical path is affected
+
+---
+
+## Risk Management
+
+### Risk Register Template
+
+| ID | Risk Description | Category | Probability | Impact | Score | Response Strategy | Owner | Status |
+|----|-----------------|----------|-------------|--------|-------|-------------------|-------|--------|
+| R-001 | Key developer leaves mid-project | Resource | High (4) | High (4) | 16 | Mitigate: Cross-train team | PM | Open |
+| R-002 | Vendor delivers late | External | Medium (3) | High (4) | 12 | Transfer: Contractual penalties | PM | Open |
+| R-003 | Requirements change after approval | Scope | High (4) | Medium (3) | 12 | Avoid: Formal change control | PM | Open |
+
+### Probability-Impact Matrix
+
+```
+              Impact
+              Low(1)  Med(2)  High(3)  Critical(4)
+Probability
+High(4)     │  4    │   8    │  12    │   16     │
+Med(3)      │  3    │   6    │   9    │   12     │
+Low(2)      │  2    │   4    │   6    │    8     │
+Rare(1)     │  1    │   2    │   3    │    4     │
+```
+
+### Risk Response Strategies
+
+| Strategy | When to Use | Example |
+|----------|-------------|---------|
+| **Avoid** | Eliminate the threat entirely | Change project approach to remove risk |
+| **Transfer** | Shift impact to third party | Insurance, contractual penalties, outsourcing |
+| **Mitigate** | Reduce probability or impact | Cross-training, prototyping, parallel paths |
+| **Accept** | Risk is low or unavoidable | Document and set aside contingency budget |
+| **Escalate** | Beyond PM authority | Notify sponsor, request organizational action |
+
+### RAID Log
+
+```markdown
+## RAID Log: [Project Name]
+
+### Risks
+| ID | Description | Owner | Status | Action |
+|----|-------------|-------|--------|--------|
+
+### Assumptions
+| ID | Assumption | Validated? | Impact if Wrong |
+|----|------------|-----------|-----------------|
+| A-001 | Budget approved by Q1 | No | Project delayed 6 weeks |
+
+### Issues
+| ID | Description | Priority | Owner | Resolution | Target Date |
+|----|-------------|----------|-------|------------|-------------|
+| I-001 | Server environment not available | P1 | IT Lead | Requested provisioning | [Date] |
+
+### Dependencies
+| ID | Description | Owner | Status | Date Needed |
+|----|-------------|-------|--------|-------------|
+| D-001 | API from Partner Team | Partner PM | In Progress | [Date] |
+```
+
+---
+
+## Status Reporting
+
+### Weekly Status Report (RAG)
+
+```markdown
+## Project Status Report: [Project Name]
+**Date**: [Date] | **PM**: [Name] | **Overall Status**: GREEN/AMBER/RED
+
+### Executive Summary
+[2-3 sentences: Current state, key accomplishments, critical items]
+
+### RAG Status
+| Area | Status | Commentary |
+|------|--------|------------|
+| Scope | GREEN | On track, no change requests |
+| Schedule | AMBER | Task X delayed 3 days, mitigation in place |
+| Budget | GREEN | 45% consumed, on plan |
+| Quality | GREEN | No critical defects |
+| Resources | AMBER | Need additional QA resource in Sprint 4 |
+
+### Accomplishments This Period
+1. [Accomplishment 1]
+2. [Accomplishment 2]
+
+### Planned Next Period
+1. [Activity 1]
+2. [Activity 2]
+
+### Risks & Issues
+| Type | Description | Impact | Action | Owner |
+|------|-------------|--------|--------|-------|
+| Risk | [Description] | [Impact] | [Action] | [Name] |
+| Issue | [Description] | [Impact] | [Action] | [Name] |
+
+### Milestones
+| Milestone | Planned | Forecast | Status |
+|-----------|---------|----------|--------|
+| [Milestone 1] | [Date] | [Date] | Complete |
+| [Milestone 2] | [Date] | [Date] | On Track |
+| [Milestone 3] | [Date] | [Date] | At Risk |
+
+### Decisions Needed
+1. [Decision needed from sponsor/steering committee]
+
+### Budget Summary
+| Category | Budget | Actual | Forecast | Variance |
+|----------|--------|--------|----------|----------|
+| Labor | $X | $Y | $Z | +/-$W |
+| Vendor | $X | $Y | $Z | +/-$W |
+| Total | $X | $Y | $Z | +/-$W |
+```
+
+### RAG Status Definitions
+
+| Status | Meaning | Action Required |
+|--------|---------|-----------------|
+| GREEN | On track, no significant issues | Continue monitoring |
+| AMBER | At risk, issues identified but manageable | PM action, stakeholder awareness |
+| RED | Off track, requires escalation | Sponsor/steering committee intervention |
+
+### Earned Value Management Basics
+
+| Metric | Formula | Interpretation |
+|--------|---------|----------------|
+| Planned Value (PV) | Budgeted cost of work scheduled | What should be done by now |
+| Earned Value (EV) | Budgeted cost of work performed | What has been done |
+| Actual Cost (AC) | Actual cost of work performed | What it cost |
+| Schedule Variance (SV) | EV - PV | Negative = behind schedule |
+| Cost Variance (CV) | EV - AC | Negative = over budget |
+| Schedule Performance Index (SPI) | EV / PV | < 1.0 = behind schedule |
+| Cost Performance Index (CPI) | EV / AC | < 1.0 = over budget |
+| Estimate at Completion (EAC) | BAC / CPI | Projected total cost |
+
+---
+
+## Stakeholder Management
+
+### RACI Matrix Template
+
+| Activity | Sponsor | PM | Tech Lead | Designer | QA | Business Owner |
+|----------|---------|-----|-----------|----------|-----|----------------|
+| Project Charter | A | R | C | - | - | I |
+| Requirements | I | A | C | C | C | R |
+| Design | I | A | C | R | I | C |
+| Development | I | A | R | C | I | - |
+| Testing | I | A | C | - | R | C |
+| Deployment | A | R | R | - | C | I |
+| Sign-off | R | A | I | I | I | R |
+
+**R** = Responsible (does the work) | **A** = Accountable (final authority) | **C** = Consulted (provides input) | **I** = Informed (kept updated)
+
+### Communication Plan
+
+| Stakeholder | Information Need | Format | Frequency | Sender |
+|-------------|-----------------|--------|-----------|--------|
+| Sponsor | Overall status, decisions | 1:1 meeting | Weekly | PM |
+| Steering Committee | Strategic status | Presentation | Monthly | PM |
+| Project Team | Tasks, blockers | Standup | Daily | Scrum Master |
+| End Users | Progress, training | Newsletter | Bi-weekly | PM |
+| Vendors | Requirements, timelines | Email/Call | As needed | PM |
+
+### Expectation Management
+
+```markdown
+## Setting Expectations Checklist
+
+1. **Define success criteria upfront** - Written, measurable, agreed upon
+2. **Communicate constraints honestly** - Budget, timeline, resources
+3. **Share risks proactively** - Don't wait for risks to become issues
+4. **Provide regular updates** - No surprises; consistent cadence
+5. **Document all agreements** - Email confirmation of verbal decisions
+6. **Manage scope formally** - All changes go through change control
+```
+
+---
+
+## Change Management
+
+### Change Request Template
+
+```markdown
+## Change Request: [CR-XXX]
+
+**Requested By**: [Name]
+**Date**: [Date]
+**Priority**: Critical / High / Medium / Low
+
+### Description
+[What is being requested]
+
+### Justification
+[Why this change is needed]
+
+### Impact Assessment
+| Area | Impact |
+|------|--------|
+| Scope | [Description of scope change] |
+| Schedule | [+/- X days/weeks] |
+| Budget | [+/- $X] |
+| Quality | [Impact on quality/testing] |
+| Resources | [Additional resources needed] |
+| Risk | [New risks introduced] |
+
+### Options
+1. **Approve as-is**: [Consequences]
+2. **Approve with modifications**: [Description]
+3. **Defer**: [When to revisit]
+4. **Reject**: [Rationale]
+
+### Recommendation
+[PM recommendation with justification]
+
+### Approval
+| Name | Role | Decision | Date |
+|------|------|----------|------|
+| [Name] | Sponsor | | |
+| [Name] | Change Board | | |
+```
+
+### Change Control Process
+
+```
+Change Requested
+    ↓
+PM Logs and Assesses Impact
+    ↓
+Impact Analysis Complete
+    ↓
+Change Board Reviews (if significant)
+    ↓
+Decision: Approve / Defer / Reject
+    ↓
+If Approved → Update Baseline → Communicate → Execute
+If Rejected → Document Rationale → Notify Requestor
+```
+
+---
+
+## Lessons Learned
+
+### Lessons Learned Template
+
+```markdown
+## Lessons Learned: [Project Name]
+**Date**: [Date]
+**Facilitator**: [Name]
+**Participants**: [Names]
+
+### What Went Well
+| Area | Description | Recommendation |
+|------|-------------|----------------|
+| Planning | WBS decomposition was thorough | Continue using WBS dictionary for all projects |
+| Communication | Weekly standups kept team aligned | Standardize standup format |
+
+### What Could Improve
+| Area | Description | Root Cause | Recommendation |
+|------|-------------|------------|----------------|
+| Estimation | Development took 30% longer | Insufficient spike time | Add prototyping phase for unknowns |
+| Scope | 4 change requests in Phase 2 | Incomplete requirements | Invest more in discovery phase |
+
+### Action Items
+| Action | Owner | Due Date | Status |
+|--------|-------|----------|--------|
+| Update estimation template | PM | [Date] | Open |
+| Create requirements checklist | BA | [Date] | Open |
+```
+
+### Project Closure Checklist
+
+- [ ] All deliverables accepted by stakeholder
+- [ ] Final status report submitted
+- [ ] Budget reconciliation completed
+- [ ] Lessons learned session conducted
+- [ ] Project documentation archived
+- [ ] Team members released and thanked
+- [ ] Vendor contracts closed
+- [ ] Outstanding risks transferred or closed
+- [ ] Post-implementation review scheduled
+
+---
+
+## Common Pitfalls
+
+### 1. Planning Without Decomposition
+
+Wrong: Jump straight to a Gantt chart with high-level tasks.
+
+Right: Build a WBS first, decompose to work packages, then schedule from the bottom up.
+
+### 2. Ignoring the Critical Path
+
+Wrong: Treat all tasks equally; scramble when the project is late.
+
+Right: Identify the critical path early. Protect it. Add buffers to feeding paths.
+
+### 3. Optimistic Estimation
+
+Wrong: "How long will it take?" "Two weeks." (Always two weeks.)
+
+Right: Use three-point estimation: (Optimistic + 4 x Most Likely + Pessimistic) / 6
+
+### 4. Change Requests Without Impact Analysis
+
+Wrong: Stakeholder asks for a change, PM says "sure" without assessing impact.
+
+Right: Every change goes through formal assessment of scope, schedule, budget, and risk impact.
+
+### 5. Status Reports That Hide Problems
+
+Wrong: Report GREEN until the project is suddenly RED.
+
+Right: Use AMBER early and often. Escalate risks before they become issues.
+
+### 6. RACI Without Accountability
+
+Wrong: Create a RACI matrix, put it in a drawer, never reference it.
+
+Right: Review RACI at kickoff, reference it when conflicts arise, update it when roles change.
+
+---
+
+## Resources
+
+- [PMBOK Guide - PMI](https://www.pmi.org/pmbok-guide-standards)
+- [Critical Chain - Eliyahu Goldratt](https://www.toc-goldratt.com/)
+- [The Deadline - Tom DeMarco](https://www.goodreads.com/book/show/123716.The_Deadline)
+- [Making Things Happen - Scott Berkun](https://scottberkun.com/making-things-happen/)
+- [Agile Estimating and Planning - Mike Cohn](https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning)