Capacity planning for a team that also sells

Capacity planning in a services business gets treated as forecasting, which is why it usually produces an argument. It is simpler than that. There is a top number, calendar weekdays, and a series of deductions. What survives the deductions is what you can sell. Everything contentious lives in the deductions.

Atlassian defines it as matching demand against supply, describing capacity planning as determining the resource needs of your project by analysing workloads, team availability and individual skillsets. In a firm that also has to win the work, availability is the part that gets overstated, because the people who deliver are the same people who sell.

Do the subtraction per person, then add up. A team-level average hides the fact that one person carries the pitch load and another carries none, and an average is not something you can staff a project against.

Several deductions are set by legislation rather than by policy, which makes them the easiest part of the plan to get exactly right and the part most often left out.

Ontario has nine public holidays, and most qualifying employees are entitled to take them off with public holiday pay. On vacation, employees with less than five years of employment are entitled to two weeks of vacation time and those with five or more years to three weeks, with vacation pay of at least four per cent of gross wages, rising to six per cent at five years.

Two leave entitlements sit alongside those. Most employees have the right to up to three days of unpaid job-protected sick leave each calendar year once they have worked for an employer for at least two consecutive weeks, and separately to up to three days of unpaid family responsibility leave each calendar year on the same qualifying period.

These are floors, not budgets. A contract may provide a greater right, and if it does, the contract applies. The point for planning is that the days exist whether or not your spreadsheet has a row for them.

The last line of the table carries more hours than all the statutory rows combined in most firms, and it is the only one that has to be measured rather than looked up. Proposal writing, scoping calls, internal review, recruitment, tooling, training, and the meetings that hold a client relationship together are all real work that produces no invoice.

Measure it for one quarter with a deliberately coarse instrument. Four buckets is enough: client delivery, selling, internal, and unavailable. Anything more granular gets abandoned by week three, which is the whole subject of time tracking people will actually do.

Then keep the measurement separated by person. A senior person spending two days a week on pitches is not a delivery resource at eighty percent, and planning a project as though they are is the single most common way a small firm ships late.

An annual capacity figure is useful for pricing and useless for scheduling, because availability is lumpy. Microsoft's Azure Boards documentation makes the distinction explicitly: velocity relates to how a team estimates requirements, while capacity relates to actual task time and takes into account variation in work hours, holidays, vacation days and nonworking days, which is why capacity is set for each sprint rather than once.

Adopt the same rhythm even if you do not run sprints. Set a planning period, put real days off into it before you commit anything, and only then decide what fits.

The advantage is that the conversation stops being about whether somebody is working hard enough. It becomes a statement of fact: this period contains this many available days, and the work you are proposing needs more of them than exist.

A capacity plan that only counts supply will always be optimistic, because demand arrives in shapes that do not match the shape of your team. Two hundred available hours of a senior data engineer do not cover eighty hours of engineering plus a hundred and twenty hours of coordination.

Break the demand side down by capability rather than by headcount, and check each capability separately. That is the same decomposition used to build a skills matrix, which is why the two artefacts should be maintained together and is covered in a skills matrix for a team of eight.

Then check the sequencing. A 154 data source migration to Tableau Cloud that ran with zero unplanned production outages consumed a defined shape of capacity in a defined order, and no headcount total would have told you whether that order was feasible.

A capacity plan can produce exactly four answers, and being explicit about which one you are looking at prevents most of the arguments that follow.

It fits. Commit and move on. It fits only if nothing goes wrong, which means it does not fit, because something will. It fits with a change to scope or date, which is a client conversation and should happen before the work starts rather than in week six. Or it does not fit at all, which is a decision about whether to subcontract, hire, or decline.

Declining is a legitimate output rather than a failure of the plan. Atlassian's framing of the planning step is that you prioritise and sequence so the important things land on time, while lower-priority work is pushed or explicitly declined. The test for when to use that output is set out in saying no to a project you could technically do.

Whichever answer you get, write down the inputs alongside it. A plan whose deductions are visible can be challenged on a specific line. A plan that produces only a total gets argued about in general terms and loses.

The plan decays. People change tenure bands and gain a week of vacation. Somebody takes on the recruitment load. A retainer grows without the fee moving. None of that announces itself, and all of it changes the number.

Recompute at a fixed cadence and keep the series. The level tells you what you can take on; the direction tells you whether last quarter's decisions did what you expected. One tracked figure settles more staffing arguments than any amount of discussion.

Feed the same figure into pricing rather than maintaining a second set of numbers. Cost per sellable hour is the denominator of a rate, which is why designing a rate card you can defend and this exercise are two halves of one calculation, and why the sequencing and dependency work that makes a plan real is what fractional technical project management exists to supply.