Project Management vs Capacity Planning

Definition

Project management is the discipline of planning, executing, and delivering work within scope, time, and resource constraints. For startups, it's not about Gantt charts — it's about shipping the right things fast. The Standish Group's CHAOS Report found that only 31% of software projects are delivered on time and on budget. The #1 predictor of success isn't the methodology (Agile vs Waterfall) — it's having clear scope definition and stakeholder alignment. Companies using structured sprint cycles ship 40% more features per quarter than those using ad-hoc approaches.

Common trap

The trap is over-investing in process at the expense of progress. A 5-person startup doesn't need Jira, Confluence, weekly status reports, and a PMO. They need a whiteboard, a 2-week sprint cycle, and a daily 15-minute standup. Conversely, a 50-person company without ANY project management will drown in coordination costs — engineers will build the same thing twice, designers will design for outdated requirements, and customer commitments will be missed. The sweet spot is the MINIMUM process that prevents coordination failures.

Practical use

Adopt time-boxed sprints (2 weeks is the industry standard). Each sprint: (1) Sprint planning — define 3-5 deliverables with clear acceptance criteria. (2) Daily standup — 15 minutes max, blockers only. (3) Sprint review — demo what shipped. (4) Sprint retro — identify 1 process improvement. Measure cycle time (idea → shipped) and sprint velocity. Target: 80% of sprint commitments delivered on time. Track the ratio of planned vs unplanned work — if unplanned exceeds 30%, you have a scope management problem.

Formula

Definition

Capacity planning is the process of determining how much work your team can handle and aligning resources to demand. The core calculation is: Available Capacity = Team Size × Working Hours × Productivity Factor (typically 0.6-0.8 after meetings, admin, and context-switching). A team of 5 engineers working 40h/week at 70% productivity has 140 productive hours/week, not 200. Companies that do capacity planning well ship 35% more features per engineering dollar by eliminating both overwork (burnout → turnover) and underutilization (idle teams → wasted salary).

Common trap

The capacity trap is planning at 100% utilization. Organizations that load teams to 95-100% see throughput DECREASE by 20-30% because there's no buffer for bugs, urgent requests, sick days, or creative thinking. McKinsey's research shows optimal knowledge work utilization is 70-85% — above that, quality drops, bugs increase, and burnout skyrockets. Another trap: headcount-based planning. Adding 1 engineer doesn't add 1 engineer's worth of output — it adds 0.5-0.7 due to onboarding, mentoring overhead, and increased communication costs (Brooks's Law).

Practical use

Calculate your team's true capacity: (Number of ICs × Weekly Hours × Productivity Factor) - Planned meetings - On-call hours = Actual Weekly Capacity. Track velocity (story points or tickets completed) over 4-week rolling average. If actual output is consistently below 70% of theoretical capacity, audit where time goes — most teams lose 30-40% to meetings, Slack, and context-switching. Set a 'capacity budget': 70% planned work, 15% unplanned/bugs, 15% tech debt and improvements.

Formula