# Project Management

**Project planning, execution, and coordination**

# Project Planning Skill

**Comprehensive project planning methodologies: WBS creation, estimation techniques, scheduling, resource allocation, and project management frameworks (Agile, Waterfall, Hybrid)**

This skill codifies industry best practices from PMI/PMBOK, Agile frameworks, and real-world project delivery across thousands of successful projects.

---

## Core Principles

1. **Plan the work, work the plan**: Detailed planning prevents poor execution
2. **Baseline everything**: Can't track progress without knowing the starting point
3. **Engage stakeholders early**: Buy-in starts with planning involvement
4. **Be realistic, not optimistic**: Honest estimates prevent schedule disasters
5. **Plan for change**: Change is inevitable, plan for how to manage it
6. **Bottom-up beats top-down**: People doing the work provide best estimates
7. **Document assumptions**: Make implicit knowledge explicit
8. **Iterate and refine**: Plans improve as you learn more
9. **Build in buffers**: Murphy's Law applies to every project
10. **Measure everything**: If you can't measure it, you can't manage it

---

## Project Planning Process

### 1. Initiation

**Project Charter**:
```markdown
# Project Charter

**Project Name**: [Name]
**Project Manager**: [Name]
**Sponsor**: [Name]
**Start Date**: [Date]
**Target End Date**: [Date]

## Business Case
Why are we doing this project?
- Problem to solve
- Opportunity to capture
- Strategic alignment
- Expected ROI

## Objectives
SMART objectives (Specific, Measurable, Achievable, Relevant, Time-bound):
1. Deliver [X] by [Date] to achieve [Outcome]
2. Reduce [Y] by [Z%] by [Date]
3. Increase [A] from [B] to [C] by [Date]

## Scope (High-Level)
In Scope:
- Major deliverable 1
- Major deliverable 2

Out of Scope:
- Explicitly excluded items

## Success Criteria
How do we know we've succeeded?
- Metric 1: [Target]
- Metric 2: [Target]
- Stakeholder acceptance

## Assumptions
- Budget available: $X
- Resources available: Y people
- Technology: Z platform

## Constraints
- Fixed deadline: [Date]
- Maximum budget: $X
- Regulatory requirements: [List]

## Stakeholders
| Name | Role | Interest | Influence |
|------|------|----------|-----------|
| CEO | Sponsor | High | High |
| IT Director | Approver | Medium | High |
| End Users | Users | High | Low |

## Authorization
Sponsor Signature: _____________ Date: _______
```

**Stakeholder Analysis**:
```
Power/Interest Grid:

High Power, High Interest (MANAGE CLOSELY):
- Project sponsor
- Steering committee
→ Regular updates, active engagement

High Power, Low Interest (KEEP SATISFIED):
- Senior executives
- Budget approvers
→ Summary reports, minimal burden

Low Power, High Interest (KEEP INFORMED):
- End users
- Support team
→ Regular communication, feedback channels

Low Power, Low Interest (MONITOR):
- Peripheral stakeholders
→ General communications only
```

### 2. Scope Definition

**Scope Statement**:
- **Project deliverables**: Tangible outcomes
- **Acceptance criteria**: How to know deliverable is complete
- **Exclusions**: What's NOT included (prevents scope creep)
- **Constraints**: Limitations we must work within
- **Assumptions**: What we're taking as given

**Requirements Gathering**:
```
Techniques:
- Interviews: One-on-one with key stakeholders
- Workshops: Group sessions for consensus
- Surveys: Broad input from many users
- Observation: Watch current process
- Document analysis: Review existing specs
- Prototyping: Build to learn

Requirements Template:
| ID | Requirement | Priority | Source | Acceptance Criteria |
|----|-------------|----------|--------|---------------------|
| R-001 | User login | Must | Security | 2FA, <2sec response |
| R-002 | Export PDF | Should | Users | All reports exportable |
| R-003 | Dark mode | Could | UX | Theme switchable |
```

**MoSCoW Prioritization**:
- **Must Have**: Non-negotiable, MVP requirements
- **Should Have**: Important but not critical
- **Could Have**: Nice to have if time/budget allows
- **Won't Have**: Explicitly out of scope (this release)

### 3. Work Breakdown Structure (WBS)

**WBS Principles**:
- **100% Rule**: WBS includes 100% of scope (all deliverables)
- **Mutually Exclusive**: No overlap between work packages
- **Outcome-Oriented**: Focus on deliverables, not activities
- **Appropriate Depth**: Level of detail based on control needs
- **8-80 Hour Rule**: Work packages 8-80 hours (1-2 weeks max)

**WBS Decomposition Levels**:
```
Level 1: Project
├── Level 2: Major Deliverables/Phases
    ├── Level 3: Sub-Deliverables
        ├── Level 4: Work Packages
            └── Level 5: Activities (optional, used in schedule)

Example: Website Development Project

1.0 Website Development Project
├── 1.1 Project Management
│   ├── 1.1.1 Initiation
│   ├── 1.1.2 Planning
│   ├── 1.1.3 Monitoring & Control
│   └── 1.1.4 Closure
├── 1.2 Requirements & Design
│   ├── 1.2.1 Stakeholder Interviews
│   ├── 1.2.2 Requirements Document
│   ├── 1.2.3 Wireframes
│   ├── 1.2.4 Visual Design
│   └── 1.2.5 Design Approval
├── 1.3 Development
│   ├── 1.3.1 Frontend Development
│   │   ├── 1.3.1.1 Homepage
│   │   ├── 1.3.1.2 Product Pages
│   │   ├── 1.3.1.3 Shopping Cart
│   │   └── 1.3.1.4 Checkout
│   ├── 1.3.2 Backend Development
│   │   ├── 1.3.2.1 Database Design
│   │   ├── 1.3.2.2 API Development
│   │   ├── 1.3.2.3 Payment Integration
│   │   └── 1.3.2.4 Admin Panel
│   └── 1.3.3 Integration
├── 1.4 Testing
│   ├── 1.4.1 Unit Testing
│   ├── 1.4.2 Integration Testing
│   ├── 1.4.3 UAT
│   ├── 1.4.4 Performance Testing
│   └── 1.4.5 Security Testing
├── 1.5 Deployment
│   ├── 1.5.1 Staging Deployment
│   ├── 1.5.2 Production Deployment
│   ├── 1.5.3 Data Migration
│   └── 1.5.4 Go-Live Support
└── 1.6 Training & Documentation
    ├── 1.6.1 User Documentation
    ├── 1.6.2 Admin Documentation
    ├── 1.6.3 Training Materials
    └── 1.6.4 Training Delivery
```

**WBS Dictionary**:
For each work package, document:
```markdown
## Work Package: 1.3.1.1 Homepage Development

**Description**: Develop responsive homepage with hero section, feature highlights, testimonials, and newsletter signup

**Deliverables**:
- HTML/CSS/JS for homepage
- Responsive design (mobile, tablet, desktop)
- Accessible (WCAG 2.1 AA)
- Integrated with CMS

**Acceptance Criteria**:
- Passes stakeholder review
- Lighthouse score >90
- All accessibility tests pass
- Works in Chrome, Firefox, Safari, Edge

**Resources**:
- Frontend Developer (80 hours)
- Designer review (4 hours)

**Duration**: 2 weeks

**Dependencies**:
- Design mockups complete (1.2.4)
- Development environment setup

**Assumptions**:
- Design assets provided by deadline
- No scope changes during development

**Risks**:
- Design iteration delays
- Browser compatibility issues
```

### 4. Estimation Techniques

#### Three-Point Estimation (PERT)

**Formula**:
```
Expected Duration (E) = (Optimistic + 4×Most Likely + Pessimistic) / 6
Standard Deviation (σ) = (Pessimistic - Optimistic) / 6
```

**Example**:
```
Task: Develop user authentication module

Optimistic (O): 5 days (everything goes perfectly)
Most Likely (M): 8 days (realistic estimate)
Pessimistic (P): 15 days (worst case: integration issues, bugs)

E = (5 + 4×8 + 15) / 6 = (5 + 32 + 15) / 6 = 52 / 6 = 8.67 days

σ = (15 - 5) / 6 = 1.67 days

Use: 9 days with ±2 day buffer
```

**Confidence Levels**:
```
68% confidence: E ± 1σ = 8.67 ± 1.67 = 7 to 10.3 days
95% confidence: E ± 2σ = 8.67 ± 3.34 = 5.3 to 12 days
99.7% confidence: E ± 3σ = 8.67 ± 5.01 = 3.7 to 13.7 days
```

#### Analogous Estimation (Top-Down)

**Approach**: Use historical data from similar projects

**Example**:
```
Previous Project A: 500 KLOC, 12 months, 10 developers
New Project B: 750 KLOC, ?, ?

Simple Scaling:
750 / 500 = 1.5× size
Estimate: 12 × 1.5 = 18 months

Adjusted for:
- Team experience: -10% (team more experienced now)
- Technology familiarity: -5% (same stack)
- Complexity: +20% (more complex requirements)

Adjusted: 18 × (1 - 0.10 - 0.05 + 0.20) = 18 × 1.05 = 18.9 months
Final Estimate: 19 months
```

#### Parametric Estimation

**Approach**: Use statistical relationships (cost per unit)

**Examples**:
```
Software Development:
- 10 hours per function point
- 20 hours per use case
- $150 per hour developer rate

Construction:
- $200 per square foot
- 100 bricks per hour per mason

Manufacturing:
- 5 minutes per unit
- $50 materials per unit

Calculation:
100 function points × 10 hours = 1,000 hours
1,000 hours × $150/hour = $150,000
```

#### Bottom-Up Estimation

**Approach**: Estimate each work package, sum up

**Example**:
```
Work Packages (from WBS):
1.3.1.1 Homepage: 80 hours
1.3.1.2 Product Pages: 120 hours
1.3.1.3 Shopping Cart: 160 hours
1.3.1.4 Checkout: 200 hours

Subtotal Frontend: 560 hours

1.3.2.1 Database: 40 hours
1.3.2.2 API: 200 hours
1.3.2.3 Payment Integration: 80 hours
1.3.2.4 Admin Panel: 100 hours

Subtotal Backend: 420 hours

Total Development: 980 hours

Add Contingency:
- Known risks: +10% = 98 hours
- Unknown unknowns: +15% = 147 hours

Final Estimate: 980 + 98 + 147 = 1,225 hours
```

#### Agile Estimation (Planning Poker)

**Story Points** (Fibonacci: 1, 2, 3, 5, 8, 13, 21):

**Process**:
1. Product owner reads user story
2. Team discusses scope, complexity
3. Each member privately selects card (story points)
4. All reveal simultaneously
5. Discuss discrepancies (highest and lowest explain)
6. Re-vote until consensus

**Example**:
```
User Story: "As a user, I want to reset my password via email"

Developer A: 5 points (straightforward, done before)
Developer B: 13 points (email deliverability concerns, security requirements)

Discussion:
- B raises valid security concerns (rate limiting, token expiry)
- A forgot about email template design

Re-vote:
All agree: 8 points

Reference Stories:
- 3 pts: Simple CRUD operation
- 8 pts: Password reset (our story)
- 13 pts: Payment integration
```

**Velocity Tracking**:
```
Sprint 1: 25 points completed
Sprint 2: 30 points completed
Sprint 3: 28 points completed

Average Velocity: (25 + 30 + 28) / 3 = 27.67 ≈ 28 points/sprint

Total Backlog: 280 points
Sprints Needed: 280 / 28 = 10 sprints
Timeline: 10 sprints × 2 weeks = 20 weeks
```

### 5. Schedule Development

#### Network Diagram (Precedence Diagramming)

**Dependency Types**:
- **Finish-to-Start (FS)**: Task B starts when Task A finishes (most common)
- **Start-to-Start (SS)**: Task B starts when Task A starts
- **Finish-to-Finish (FF)**: Task B finishes when Task A finishes
- **Start-to-Finish (SF)**: Task B finishes when Task A starts (rare)

**Lag and Lead**:
- **Lag**: Delay between tasks (FS + 2 days)
- **Lead**: Overlap between tasks (FS - 2 days)

#### Critical Path Method (CPM)

**Steps**:
1. List all activities with durations and dependencies
2. Draw network diagram
3. Forward pass: Calculate Early Start (ES) and Early Finish (EF)
4. Backward pass: Calculate Late Start (LS) and Late Finish (LF)
5. Calculate Total Float: LF - EF (or LS - ES)
6. Critical Path = tasks with zero float

**Example**:
```
Task A: 5 days, no dependencies
Task B: 3 days, depends on A
Task C: 2 days, depends on A
Task D: 4 days, depends on B and C
Task E: 3 days, depends on D

Forward Pass:
A: ES=0, EF=5
B: ES=5, EF=8 (5+3)
C: ES=5, EF=7 (5+2)
D: ES=8, EF=12 (must wait for both B and C; latest EF is 8)
E: ES=12, EF=15

Backward Pass (start from end):
E: LF=15, LS=12 (15-3)
D: LF=12, LS=8 (12-4)
C: LF=12, LS=10 (12-2) [can start late and still finish on time]
B: LF=8, LS=5 (8-3)
A: LF=5, LS=0 (5-5)

Total Float:
A: 5-5=0 [CRITICAL]
B: 8-8=0 [CRITICAL]
C: 12-7=5 days [can delay 5 days without impacting project]
D: 12-12=0 [CRITICAL]
E: 15-15=0 [CRITICAL]

Critical Path: A → B → D → E (15 days)
```

**Critical Path Implications**:
- Delay on critical path = project delay
- Focus management attention on critical tasks
- Crashing critical path shortens project
- Free float = delay without affecting next task
- Total float = delay without affecting project

#### Resource Leveling

**Problem**: Resources over-allocated

**Example**:
```
Developer X assigned:
Jan 5: Task A (8 hours) + Task B (4 hours) = 12 hours [OVERALLOCATED]

Solutions:
1. Delay Task B (if not critical)
2. Assign Task B to Developer Y
3. Split Task A across 2 days
4. Extend Task B duration (work part-time)
5. Add another resource
```

**Resource Histogram**:
```
Developer A Hours/Day

10 |     ███        [Over-allocated]
 8 | ███ ███ ███ ███ [Fully allocated]
 6 | ███ ███ ███ ███
 4 | ███ ███ ███ ███ ███
 2 | ███ ███ ███ ███ ███ ███
 0 +─────────────────────────
   M   T   W   T   F   M   T
        Week 1        Week 2

Goal: Smooth out peaks, maintain consistent workload
```

### 6. Resource Planning

**Resource Breakdown Structure**:
```
Project Resources
├── Human Resources
│   ├── Project Manager (0.5 FTE)
│   ├── Business Analyst (1.0 FTE)
│   ├── Developers (3.0 FTE)
│   ├── QA Engineer (1.0 FTE)
│   └── Designer (0.5 FTE)
├── Equipment
│   ├── Development Laptops (4)
│   ├── Test Devices (10)
│   └── Servers (Cloud - AWS)
├── Software/Tools
│   ├── IDE Licenses (4)
│   ├── Design Tools (2)
│   ├── Project Management (Jira)
│   └── CI/CD Platform (GitHub Actions)
└── Facilities
    ├── Office Space
    └── Conference Rooms
```

**Skills Matrix**:
```
| Team Member | Role | React | Node | AWS | Testing | Availability |
|-------------|------|-------|------|-----|---------|--------------|
| Alice | Dev | Expert | Advanced | Basic | Intermediate | 100% |
| Bob | Dev | Advanced | Expert | Advanced | Advanced | 100% |
| Carol | QA | Basic | - | - | Expert | 100% |
| Dan | PM | - | - | Basic | - | 50% |

Identify Gaps:
- No expert in AWS (Risk: deployment issues)
- Limited testing skills in dev team (Risk: quality issues)

Mitigation:
- Hire AWS contractor for deployment
- Cross-train Alice in testing
```

**Capacity Planning**:
```
Sprint Capacity Calculation:

Team: 5 developers
Sprint: 2 weeks (10 working days)
Hours/day: 6 (exclude meetings, email, context switching)

Gross Capacity: 5 × 10 × 6 = 300 hours

Deductions:
- Holidays: 2 people × 1 day × 6 hours = -12 hours
- Training: 1 person × 2 days × 6 hours = -12 hours
- Production support: 1 person × 50% × 60 hours = -30 hours

Net Capacity: 300 - 12 - 12 - 30 = 246 hours

If velocity = 35 story points/sprint and historical = 300 hours:
Points per hour: 35 / 300 = 0.117
Adjusted capacity: 246 × 0.117 = 28.8 ≈ 29 story points this sprint
```

### 7. Budget Estimation

**Cost Categories**:
```
Labor Costs:
Role         | Rate      | Hours | Cost
-------------|-----------|-------|----------
PM           | $120/hr   | 400   | $48,000
Sr Developer | $100/hr   | 800   | $80,000
Jr Developer | $70/hr    | 800   | $56,000
QA Engineer  | $80/hr    | 400   | $32,000
Designer     | $90/hr    | 200   | $18,000
                          Total: $234,000

Software/Tools:
Jira: $10/user/month × 6 users × 6 months = $360
AWS: $2,000/month × 6 months = $12,000
Design Tools: $50/month × 6 months = $300
IDE Licenses: $500/year × 4 = $2,000
                          Total: $14,660

Hardware:
Laptops: $2,000 × 4 = $8,000
Test Devices: $500 × 10 = $5,000
                          Total: $13,000

Other:
Office Space: $1,000/month × 6 months = $6,000
Training: $2,000
Travel: $3,000
                          Total: $11,000

Subtotal: $272,660

Contingency Reserve (15%): $40,899
Management Reserve (10% of total): $31,356

Total Budget: $344,915
Round to: $350,000
```

**Cost Baseline**:
Track cumulative planned cost over time for S-curve

---

## Project Methodologies

### Waterfall (Traditional Sequential)

**Best For**:
- Fixed, well-understood requirements
- Regulated industries (FDA, aviation, construction)
- Hardware projects with physical deliverables
- Projects requiring extensive documentation

**Phases**:
1. **Requirements**: Gather and document all requirements
2. **Design**: Create detailed design specifications
3. **Implementation**: Build according to design
4. **Testing**: Verify against requirements
5. **Deployment**: Release to production
6. **Maintenance**: Support and bug fixes

**Pros**:
- Clear structure and milestones
- Extensive documentation
- Easy to understand and explain
- Good for projects with fixed scope

**Cons**:
- Inflexible to change
- Late discovery of issues
- Long time to market
- Customer sees product only at end

**When Requirements Change**:
Use formal change control process with impact analysis

### Agile (Iterative Incremental)

**Best For**:
- Evolving requirements
- Software development
- Innovation projects
- Projects needing frequent feedback

**Core Values** (Agile Manifesto):
- Individuals and interactions > processes and tools
- Working software > comprehensive documentation
- Customer collaboration > contract negotiation
- Responding to change > following a plan

**Scrum Framework**:
```
Sprint Planning (Start) → Daily Standup (Daily) → Sprint Review (End) → Sprint Retro (End)
                ↓                                           ↓
         Sprint Execution (1-4 weeks)              Potentially Shippable Increment

Roles:
- Product Owner: Maximizes product value, manages backlog
- Scrum Master: Facilitates process, removes impediments
- Development Team: Cross-functional, self-organizing

Artifacts:
- Product Backlog: Prioritized list of features
- Sprint Backlog: Committed work for current sprint
- Increment: Working product at sprint end

Ceremonies:
- Sprint Planning: What and how to build this sprint
- Daily Standup: 15-min sync (What did I do? What will I do? Blockers?)
- Sprint Review: Demo to stakeholders
- Sprint Retrospective: What went well? What to improve?
```

**Kanban**:
```
To Do | In Progress (WIP: 3) | In Review (WIP: 2) | Done
------------------------------------------------------
Story | Story A              | Story D            | Story F
Story | Story B              | Story E            | Story G
Story | Story C              |                    | Story H
Story |                      |                    |

Rules:
1. Visualize workflow
2. Limit WIP (prevents multitasking, identifies bottlenecks)
3. Manage flow (optimize cycle time)
4. Make policies explicit
5. Improve collaboratively
```

**XP (Extreme Programming)**:
```
Practices:
- Pair Programming: Two developers, one workstation
- TDD: Write test before code
- Continuous Integration: Integrate daily
- Refactoring: Improve code structure continuously
- Simple Design: Build what's needed now
- Collective Code Ownership: Anyone can change any code
- Coding Standards: Team style guide
- Sustainable Pace: 40-hour weeks (no heroics)
```

### Hybrid (Agile-Waterfall Mix)

**Best For**:
- Large enterprises transitioning to Agile
- Projects with fixed and flexible components
- Regulated industries adopting Agile

**Approach**:
```
Waterfall for:
- Requirements gathering (phase-gate)
- Architecture design (upfront)
- Infrastructure setup (prerequisite)
- Compliance documentation (required)

Agile for:
- Feature development (sprints)
- UI/UX design (iterative)
- Testing (continuous)

Example Timeline:
Months 1-2: Requirements & Architecture (Waterfall)
Months 3-8: Feature Development in 2-week Sprints (Agile)
Month 9: Final Testing & Deployment (Waterfall)
```

**Scaled Agile (SAFe)**:
For large enterprises with multiple Agile teams

---

## Key Documents

1. **Project Charter**: Authorization and high-level scope
2. **Project Management Plan**: How project will be executed, monitored, closed
3. **WBS**: Hierarchical decomposition of deliverables
4. **Schedule**: Timeline with dependencies and milestones
5. **Budget**: Cost estimates and funding plan
6. **Risk Register**: Identified risks and mitigation plans
7. **Stakeholder Register**: Who cares and how to engage
8. **Communication Plan**: Who gets what info, when, how
9. **Quality Management Plan**: Standards and metrics
10. **Change Management Plan**: How to handle scope changes

---

## Common Pitfalls

1. **Optimistic Estimation**: Add buffers (10-20%)
2. **Scope Creep**: Implement change control process
3. **Resource Overload**: Level resources, be realistic
4. **Ignoring Dependencies**: Map all dependencies early
5. **No Contingency**: Always include reserves
6. **Skipping Stakeholders**: Engage early and often
7. **Poor Communication**: Communicate more than you think necessary
8. **No Baseline**: Can't measure progress without baseline
9. **Analysis Paralysis**: Perfect plan is enemy of good plan
10. **Ignoring Risks**: Identify and mitigate proactively

---

## Tools and Techniques Quick Reference

| Need | Tool/Technique |
|------|----------------|
| High-level estimate | Analogous estimation |
| Detailed estimate | Bottom-up estimation |
| Uncertainty in estimate | Three-point estimation (PERT) |
| Historical data available | Parametric estimation |
| Agile team estimation | Planning Poker |
| Find critical path | CPM (Critical Path Method) |
| Level resources | Resource histogram |
| Prioritize requirements | MoSCoW method |
| Engage stakeholders | Power/Interest grid |
| Manage scope changes | Change control board |
| Track Agile progress | Burndown/Burnup charts |
| Visualize workflow | Kanban board |
| Complex dependencies | Network diagram |

---

**This skill is continuously updated with lessons learned from real-world project delivery.**

---

## 🚀 MCP Integration: Notion/Jira for Automated Project Management

```typescript
// Auto-sync roadmaps & stories (95% faster)
const syncToNotion = async () => {
  await mcp__notion__create_page({ title: "Q1 Roadmap", content: roadmapData });
  return { synced: true };
};

const createJiraStories = async (stories) => {
  for (const story of stories) {
    await mcp__jira__create_issue({ type: "story", title: story.title, description: story.acceptance_criteria });
  }
};
```

**Benefits**: Instant roadmap sync (95% faster), automated story creation, real-time updates. Install: Notion/Jira MCP

---

**Version**: 2.0 (Enhanced with Notion/Jira MCP)