Skip to content
Menu

Build Project Capacity Planning Around the Work Already Sold

Build project capacity planning from billed hours, unpaid onboarding, and real delivery dates to decide when your MSP needs more engineering capacity.

MSP coordinator and engineer review client projects and onboarding for project capacity planning

Project capacity planning must include unpaid onboarding as well as sold project work. The MSP model gives a project engineer 1,660 available hours a year at 85% utilization. For that planning assumption, calculate annual productive capacity as 1,660 × 85% = 1,411 hours, then divide by 12 for about 117.58 hours a month. Fill those hours with the work already promised before offering another start date.

Then put the work on a calendar. An annual average can fit while a particular delivery period is overloaded. I'd make the next hire decision from that dated workload and the skills it needs, with the model as the starting calculation.

Count the Work You Have Already Sold

Build a project list with an owner, remaining estimated labor, required skills, client dependencies, and the agreed delivery dates. Use remaining work rather than the original quote. An estimate that hasn't been updated after discovery isn't much use for assigning next week's engineer.

Separate committed work from opportunities that might close. Keep prospective projects visible with their likely dates and the assumptions behind them. Don't count every opportunity as sold, and don't hide the sales pipeline until its contracts arrive at the delivery team's door.

On MSP Mastery, Brendan Rose recommends viewing sold project hours, prospective work with expected dates and likelihood, and the team's delivery rate together. He uses that view to discuss resourcing and realistic sales timing. That's a practitioner's planning approach, not a promise that the pipeline will arrive as expected.

Ask sales to check a proposed start date with the project owner before promising it. Where prerequisites or capacity aren't established, make the scheduling condition explicit. Keep the date on the capacity plan consistent with what the client was told.

Put Free Onboarding on the Same Plan

The model assigns onboarding to project engineers. It assumes 60 hours per new client and an onboarding fee that is quoted and then waived for the signed agreement. Free to the client still means paid work for the MSP.

For a hypothetical plan using the US stable example, calculate monthly billed project effort as $290,769 annual project revenue ÷ $185 per hour ÷ 12, or about 131.0 hours. Calculate monthly onboarding as $218,077 annual sales and marketing spending ÷ $25,000 acquisition cost per new client × 60 onboarding hours ÷ 12, or about 43.6 hours. Add 131.0 + 43.6 = 174.6 hours, then divide by 117.58 productive hours per engineer to calculate about 1.48 project FTE, meaning full-time equivalent capacity.

Billed projects alone need about 1.11 FTE. The remaining 0.37 FTE is onboarding. A plan based only on project invoices would omit that work while leaving the engineers to deliver it.

For the growth calculation, keep the same billed-project inputs and substitute $363,462 annual sales and marketing spending: $363,462 ÷ $25,000 × 60 ÷ 12 gives about 72.7 monthly onboarding hours. Using the same hypothetical plan, calculate (131.0 + 72.7) ÷ 117.58 to get about 1.73 project FTE. Sales growth changes the workload even though that onboarding produces no project fee.

Use the model's 60 hours to build an initial plan, then compare it with actual onboarding records and the assessed environment. Keep separately scoped remediation visible. Don't quietly squeeze discoveries into the original estimate so the plan still fits.

Turn FTE Into Named Calendar Capacity

The 1.48 FTE requirement is a planning amount, not a roster. You still need people with the required skills available when the work must happen. The fractional result doesn't identify who can perform the work or when they can attend a client site.

For each engineer, start with their real schedule for the delivery period. Account for leave, existing assignments, travel, client access windows, and other known constraints. Reconcile that view with the annual model, taking care not to subtract the same unavailable time twice.

The 85% assumption is for dedicated project engineers without escalation duty. If your senior technician also covers support escalation, record that obligation explicitly. Don't give the person a full project allocation and then assume the desk can interrupt it at no cost.

Compare work and availability by the skill and delivery period that matters. A future opening elsewhere on the calendar doesn't solve a clash between agreed cutovers. A total that balances across the team doesn't establish that the required engineer is available.

Choose What Changes Before Choosing the Hire

When the dated plan shows a gap, ask what is driving it. An inaccurate remaining estimate, a blocked client dependency, and a sustained increase in sold work need different decisions. Move a date only through the appropriate client and internal agreement.

I would give the project owner a short decision list, with the effect on the commitments written beside each choice.

  • The project owner updates remaining estimates and dependencies, then identifies the particular periods and skills that are short.
  • The sales lead checks whether prospective start dates can change before they become commitments.
  • The operations owner checks whether named internal capacity can be reassigned without double-booking support or other projects.
  • The technical lead assesses any proposed external help against the work, access, and supervision it would require.
  • The owner and finance lead compare the sustained gap with the actual cost and availability of a hire, then approve a funded staffing plan.

An external resource needs a real quote and a workable handoff. An internal reassignment needs an honest account of the work displaced. Neither is free capacity because the spreadsheet has a spare row.

Cost the Hire Before Counting Its Hours

The model's US project engineer salary is $84,000. Applying its general 1.25 burden multiplier gives $105,000 annually in burdened pay. That is a planning cost for the role, not a recruiting quote for your location.

The multiplier excludes bonuses, recruiting, training, equipment, and software. Include the relevant actual costs in the hiring plan without counting them twice elsewhere. Also identify when the person can realistically start and what work they can initially own.

Don't assume the full productive-hours allowance is available from the offer date. Use the actual hiring and preparation plan to schedule work. The model supplies no universal hiring lead time or ramp-up period.

Before approving the role, finance should show how the additional payroll and setup costs are funded over the period when they arise. The project owner should show the work assigned to that capacity. A utilization percentage alone doesn't establish that the cash or demand is there.

Keep the Plan Current as the Work Changes

Review the plan when a project is sold, an estimate changes materially, a dependency moves, or staffing availability changes. Keep the agreed delivery date separate from the latest forecast so the effect of a change stays visible. Assign the client conversation when those dates no longer align.

Track actual project and onboarding labor separately against their estimates. Use the differences to improve the next remaining-work forecast. A task taking longer than expected is something to investigate before treating it as proof that another engineer is needed.

Take the earliest overloaded delivery period on your current plan and name the work that won't fit. Decide who changes the scope, date, or capacity, and record the effect on the client commitment. That is the hiring conversation worth having: specific work, a real calendar, and a funded way to deliver it.

Written ByMegan Friesen

Staff Writer, Operations and People. Megan Friesen covers the business of running an MSP for MSP Outpost: service delivery, people and the ticket board. She judges every idea by what it does on Monday morning.

More by Megan

mspoutpost.com/articles/build-project-capacity-planning-around-the-work-already-sold

Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.

Sources1
  1. Practitioner capacity-planning approach: Brendan Rose recommends viewing sold project hours, prospective work with expected dates and likelihood, and the team’s project delivery rate together. He describes using that view to discuss priorities and rebuzzsprout.com

Welcome Back

Sign in to your MSP Outpost account.