93 lines
2.8 KiB
Markdown
93 lines
2.8 KiB
Markdown
Duration: 30--40 minutes
|
|
|
|
## Definition
|
|
|
|
Capacity is the amount of work a person or team can realistically take
|
|
on. Work in Progress (WIP) is work started but not finished. A WIP limit
|
|
deliberately restricts concurrent work.
|
|
|
|
## Simple Mental Model
|
|
|
|
**Starting more does not mean finishing more.**
|
|
|
|
## How It Works
|
|
|
|
A 35-hour work week is not 35 project hours:
|
|
|
|
``` text
|
|
35 hours
|
|
├── 10h operations/tickets
|
|
├── 5h meetings/admin
|
|
├── 5h support/incidents
|
|
└── 15h project capacity
|
|
```
|
|
|
|
The exact split varies. The principle is that operational work consumes
|
|
real capacity.
|
|
|
|
Capacity also depends on specialties. You can have available developer
|
|
capacity while QA is overloaded, making QA the bottleneck.
|
|
|
|
Too much WIP creates context switching:
|
|
|
|
> Start → interrupt → switch → wait → restart
|
|
|
|
Reducing WIP can increase throughput even though fewer projects appear
|
|
active.
|
|
|
|
### Example
|
|
|
|
Two integrators each have four active projects plus tickets. After a
|
|
month, all eight projects moved slightly but none finished. Limiting
|
|
major active projects can produce fewer "In Progress" rows but more
|
|
completed outcomes.
|
|
|
|
### My Company / Real-World Context
|
|
|
|
Your team handles projects, Product work, Jira tickets, synchronization
|
|
incidents, QA, Data, SEO/WCAG, and meetings. Your portfolio should
|
|
eventually show what is truly active and what is intentionally queued.
|
|
|
|
Operational interruptions that happen every week are not exceptional.
|
|
Planning should account for them.
|
|
|
|
### CTO Perspective
|
|
|
|
If leadership wants ten initiatives but the organization can reliably
|
|
execute four, expose the constraint. Choices include doing fewer things,
|
|
reducing scope, extending timelines, adding capacity, reducing
|
|
operational load, improving automation, or accepting risk.
|
|
|
|
### Questions to Ask
|
|
|
|
- How much project capacity do we actually have?
|
|
- What percentage is regularly consumed by operations?
|
|
- How many projects are active per owner?
|
|
- Which role is the bottleneck?
|
|
- What should remain queued?
|
|
- What does a new project displace?
|
|
|
|
### Key Takeaways
|
|
|
|
- Theoretical hours are not project capacity.
|
|
- Operations consume capacity and should be planned for.
|
|
- Too much WIP creates context switching and unfinished work.
|
|
- WIP limits help teams finish before starting more.
|
|
- Bottlenecks may be role-specific.
|
|
- A healthy portfolio contains queued work, not only active work.
|
|
|
|
## How It Fits Into the Bigger Picture
|
|
|
|
This lesson builds on [[Projects vs Operations]], [[Outcomes and Definition of Done]], [[Scope and Scope Creep]], and [[Milestones vs Tasks]]. It prepares the project system to become
|
|
more predictable and scalable.
|
|
|
|
## Related Concepts
|
|
|
|
- [[Milestones vs Tasks]]
|
|
- [[Dependencies]]
|
|
- [[Estimation and Forecasting]]
|
|
- [[Prioritization]]
|
|
- [[Risk Management]]
|
|
- [[Project Health]]
|
|
- [[Portfolio Management]]
|