Project count is attractive because it is easy to measure. It also hides most of the information that actually determines whether a technical delivery team has capacity.
A penetration test can be a small external assessment with clean access and one tester, or a multi-service engagement involving application testing, APIs, cloud, internal networks, multiple stakeholders, client dependencies, reporting, QA, and remediation. Calling both of those “one project” is operationally meaningless.
Capacity has weight
The useful question is not “How many projects does this person have?” It is “How much delivery load does this work create?” That load is shaped by testing hours, complexity, coordination, specialized skill requirements, QA responsibilities, client readiness, reporting effort, and how many things can interrupt the plan.
The same principle applies to PMs. A quiet engagement in preparation can require almost no attention for days. A technically blocked assessment with an unhappy client can consume hours of coordination even if the scheduled testing effort is small.
Availability is not the same as usable capacity
A tester can have open hours on a calendar and still be the wrong resource. The engagement may require a skill they do not have, overlap with a QA rotation, depend on access that is not ready, or create too much context switching around other work.
This is why staffing needs to consider capability and delivery conditions, not just free time.
A better operating view
I prefer a lightweight model that combines scheduled testing hours with project weight. The exact formula matters less than making the hidden load visible. A useful view usually includes testing effort, service complexity, coordination burden, QA commitments, readiness risk, and whether the work depends on scarce expertise.
The goal is not to build a perfect scoring system. The goal is to stop pretending that every row on a project list costs the team the same amount of attention.
Why this matters
Bad capacity models create the same pattern repeatedly: the calendar looks fine, more work gets accepted, delivery becomes reactive, contractors are added late, QA gets compressed, and the team absorbs the gap through overtime or context switching.
That is not a utilization problem. It is a visibility problem.
Capacity planning should give leaders enough signal to make an earlier decision: move work, change the window, add qualified coverage, reduce scope, or say no. That is a much healthier operating model than waiting for the team to prove it is overloaded.