Development Agency Capacity: Plan Review Work Before Taking More Projects

A software agency has capacity for another project only when the required engineering, design, review, testing, and coordination work can fit alongside existing commitments. Count the constrained roles and handoffs, not just available developers. Extra implementation hours do not automatically create more senior review or release capacity.

Atlassian frames capacity around workload, availability, and relevant skills. Atlassian capacity-planning guidance. Atlassian connects refinement with work that is understood and ready to estimate. Atlassian backlog-refinement guidance. The practical workflow below is a proposed management approach, not a claim that a particular tool or provider produces guaranteed results.

Map the whole delivery path

For the proposed project, identify the types of work needed from discovery through operating handover. Ask which activities depend on a specific skill or reviewer. Include customer decision points that can block the team even when internal people are available.

The aim is a useful planning model, not a perfect prediction. A small agency can begin with a role-based view of the next planning period. A more complex agency may need detailed allocation. In either case, qualified delivery leaders should validate the assumptions before sales turns an indicative window into a customer commitment.

Make hidden work visible

Review responsibilities that do not always appear as project tasks: code review, technical guidance, production support, presales input, leave, onboarding, and review of customer changes. Decide how these will be represented so the same person's time is not promised repeatedly.

• Which role must perform or approve the work?
• What existing commitments already use that role?
• Which work can run in parallel and which must wait?
• What information is needed before an item can be estimated or started?
• Which customer decisions influence sequencing?
• Who can approve a change to a delivery commitment?

Use evidence from your own operation to refine the model. Do not assume a universal utilization percentage, developer-to-reviewer ratio, or fixed velocity. Those figures can hide important differences in project complexity, team experience, support responsibilities, and the quality of requirements.

Separate a demand forecast from committed work

Sales opportunities are potential demand. Executed engagements and accepted delivery responsibilities are commitments. Show both, but do not combine them into a single schedule without stating the assumptions. An owner needs to see the effect of a possible win before it becomes a confirmed obligation.

Agree when delivery reviews a proposed project and who can approve its start window. If several opportunities compete for the same constrained role, make the trade-off explicit. A salesperson should not quietly reserve a senior engineer while the delivery lead assumes that person is available for another account.

Check readiness as well as staffing

An unrefined backlog or unresolved integration can make nominal capacity difficult to use. Confirm that the next work is sufficiently understood, the customer can provide decisions, and technical prerequisites are in place. Otherwise the team may start several engagements while all of them wait for different inputs.

Keep blocked work visible without treating it as ready work. The response to a missing customer decision may be escalation or resequencing. The response to a real skill shortage may be a later start or an approved capacity change. These are different management decisions.

Illustrative example: implementation capacity exceeds review capacity

Suppose an agency has several developers available for new work, but one senior engineer must review the architecture and critical changes across its current projects. Sales sees room for another engagement because developer allocations look light. This example is illustrative.

The capacity review shows where the new project needs senior input and what that person already owns. The delivery lead can change sequencing, appoint another qualified reviewer, reduce concurrent commitments, or propose a different start window. It should not promise the work first and hope the bottleneck resolves itself later.

The decision also needs customer communication. If an account's schedule changes, its owner should understand why and what remains possible. Avoid solving an internal planning conflict by sending a vague delay message after the original date has already become unrealistic.

Manage work in progress deliberately

Starting more projects can increase coordination and context-switching. Decide how many concurrent obligations each constrained role can reasonably manage, based on observed work. A limit should help the team finish useful work, not become a rigid target detached from customer needs.

When an urgent request arrives, identify what it displaces and who approves the change. Do not assume the team can absorb it because the request seems small. Technical review, testing, and customer acceptance can matter even when the visible feature is modest.

Review commitments using causes, not blame

Track work waiting for review, starts moved because of internal capacity, blocked customer decisions, and repeated estimate changes caused by unclear requirements. Review the causes with the people doing the work. A chart of utilization alone will not explain why delivery feels overloaded.

Start by mapping the next few projects through the role most often interrupting the founder. Make its real commitments visible, establish a clear approval route, and review the next planning cycle. Better ownership of the constraint can be more useful than adding another developer without changing how work reaches completion.

Put clear ownership around the work

Escencion provides Managed Sales & Business Operations for technology companies. Our current client focus is MSPs and MSSPs. Explore our Managed Business Operations approach, or discuss the responsibilities you need managed. Your technical team retains technical validation, approved commitments, engineering, and service delivery.