Bandwidth

"Do you have bandwidth for this?" It's become the polite way of asking "can you take on more work without imploding?" — and it's also one of the most poorly answered questions in agency life. People say yes when they shouldn't, because they don't actually *know* how much capacity they have left. They're guessing based on how busy they *feel*, not on data.

Bandwidth is the gap between what someone is currently committed to and their total availability. If a developer has 160 hours this month and 120 are already allocated to existing projects, their bandwidth is 40 hours. Simple subtraction — but only if you actually know both numbers.

Bandwidth vs. Capacity vs. Availability

These three get tangled up constantly, so let's untangle them:

• Capacity is the theoretical maximum — total hours a person or team could work in a period (typically 160h/month for full-time).
• Availability is capacity minus time off and public holidays — the hours they're actually around.
• Bandwidth is availability minus current allocations — the hours that are free for *new* work.

A designer with 160h capacity, 16h of vacation, and 100h of existing project work has: 160 - 16 = 144h availability, and 144 - 100 = 44h bandwidth. That 44 hours is what you can safely commit to a new project without creating overallocation.

Why "I'm Pretty Free" Doesn't Cut It

People are terrible at estimating their own bandwidth. Studies on planning fallacy show we consistently underestimate how much time our current commitments take and overestimate how much slack we have. A PM asks "can you squeeze in 20 hours of work next week?" and the answer is "sure" — until you add up the three other projects, the two recurring meetings, and the code review backlog that already fills the calendar.

This is why bandwidth needs to be calculated, not felt. A timeline view that shows current allocations against total availability makes the math visible. You don't ask someone if they're free — you *see* that they have 32 hours of uncommitted time next week.

Team Bandwidth and Pipeline Decisions

Bandwidth becomes especially powerful at the team level. If your design team has 200 hours of collective bandwidth over the next month, you know you can confidently take on a 180-hour project. If bandwidth is at 40 hours, that same project either waits, goes to contractors, or triggers a headcount planning conversation.

This is the bridge between sales and operations. When your business development team asks "can we pitch this project for a March start?", the answer lives in your bandwidth data — not in a hallway conversation with the team lead who says "yeah, probably" without checking the schedule.

WrkSched's capacity planning report shows bandwidth by person and by team — available hours minus scheduled hours, color-coded so you can spot who has room and who doesn't at a glance. It turns a subjective question into an objective one.