A weekly capacity meeting for a 15-tech MSP

At around fifteen technicians, an MSP stops being able to plan in one person’s head. There are enough projects running at once that two cutovers land in the same week, enough service-desk load that project engineers get pulled onto tickets, and enough people that someone is always on leave. The service delivery manager knows most of it. Most of it is not enough.

The fix is not a planning tool on its own. It is a short meeting, held every week, that looks at the same numbers in the same order and ends with decisions. Here is a format that works for a team of around fifteen.

Who comes

Keep it small. Four or five people:

• The service delivery manager, who chairs it and owns the decisions.
• The project managers, or the lead engineer on each major project if you don’t have dedicated PMs.
• The service desk lead, because the service desk is the biggest single claim on everyone’s time and the one that is never on a project plan.

The technicians don’t need to attend. They need to see the outcome, and they need their timesheets and leave to be up to date before the meeting starts.

What to prepare

The meeting is only as good as its inputs. By the time it starts:

• Last week’s time is submitted and approved. Planning on half-entered timesheets is planning on guesses.
• Leave is entered, including the half day for the dentist and the public holiday in one office that isn’t in the other.
• Project task dates and estimates are current, at least for the next two weeks.
• Service-desk load is known. Look at how much ticket time each person has carried over the last few weeks. It is the best predictor of how much they will carry next week.

The capacity sum

For each person, each week:

available hours = contracted hours − leave − public holidays

load = project bookings + reserved hours (rota, pre-sales, training) + expected service-desk time

As an illustration, fifteen technicians on 38 hours a week have 570 hours. Take off a week of leave for one person and a public holiday for five more, and you are at about 500. If the service desk reliably uses 180 of those hours, there are around 320 hours for projects, not 570. Most overbooking comes from planning against the 570.

The agenda: 30 minutes

1. Last week, five minutes. What was planned against what happened. Not to assign blame: to calibrate. If one project took twice its booked hours, its remaining estimate is probably wrong too. If the service desk took 40% more than usual, find out why before assuming it will again.

2. The next two weeks, fifteen minutes. This is the heart of it. Go person by person, looking only at anyone over about 85% loaded or over capacity. For each one, decide: move a task, move a date, move the work to someone with room, or accept it knowingly for one week. Every red cell leaves the meeting with a decision.

3. Weeks three to eight, five minutes. The horizon. New projects starting, go-lives, large leave. You are not solving these weeks yet, just spotting the collision early enough that solving it is cheap. Two migrations planned for the same fortnight is a phone call now and a crisis later.

4. Decisions and owners, five minutes. Read back what was decided and who is doing it: the date that moves, the customer who needs telling, the booking that changes. Then make the changes in the system before people leave the room, so the plan matches the decisions.

Rules that keep it honest

Plan to 80–85%, not 100%. An engineer booked at 100% of their available hours has no room for the P1 that will happen. Planning to 85% is not slack; it is admitting that the service desk is not fully predictable.

Reserve the rota. If someone is on the service desk rota two days a week, reserve those hours explicitly. Don’t let project bookings use them and hope.

Never book over leave. It sounds obvious. It happens every week in teams that keep leave in a different place from the plan.

Count the people who aren’t on projects. Service-desk technicians who never touch a project still need to be in the plan, because they are who the project engineers get swapped with when things go wrong.

One owner per decision. “We’ll sort it out” is not a decision.

What good looks like after a month

After four or five weeks of this, a few things change. Red cells in the two-week view get rarer, because they were spotted in the eight-week view first. Project managers stop discovering conflicts on the Monday of the week they happen. Customers hear about date changes earlier, which they prefer even when they don’t like it. And the conversation shifts from “who can we pull onto this?” to “what can we commit to next month?”

Where ProjectSmith fits

ProjectSmith’s capacity grid is built for exactly this meeting. It shows every Autotask resource by week, with capacity after leave and public holidays, against project bookings, task estimates, reserved hours and service-desk load from Autotask ticket time, and turns amber at 85% and red over capacity. See how capacity planning with Autotask works, and how the portfolio Gantt helps with the eight-week view.