Project Management for IT and Managed Service Providers
A practical guide to project management for IT and managed service providers, covering the structural conflict between tickets and projects, ring-fencing capacity, running client onboarding as a repeatable project, and tracking client profitability.
Everything else follows from that structural point. An MSP with excellent project management practice and no capacity protection will still deliver projects late, because the engineer scheduled for the migration spent Tuesday on a printer.
Quick answer: The defining problem for an MSP is that project work and ticket work draw on the same engineers, and tickets always win. Managing projects successfully means ring-fencing capacity structurally rather than intending to protect it, templating repeatable work like client onboarding, and tracking profitability per client rather than in aggregate.
The Structural Problem: Projects Compete With Tickets
MSPs run two demand streams — reactive support and planned projects — through one pool of engineers, and the reactive stream has all the urgency.
Two demand streams, one team
Tickets arrive unpredictably with client-visible SLAs attached. Projects are planned, scheduled and internally visible.
Both are real work, and they need different management. Tickets suit continuous flow with response-time targets; projects suit planned delivery with milestones. Running both through one undifferentiated queue means the project work exists in whatever time is left, which is not a plan.
Why projects always lose
The incentives point one way. A breached SLA is visible to the client immediately; a project slipping a week is visible to nobody until later.
Any engineer choosing between an escalating ticket and project work will choose the ticket, correctly. This is not a discipline problem to be solved with encouragement.
What separation actually requires
Intentions do not survive a busy Tuesday. Separation has to be structural — an engineer taken off the ticket queue entirely for defined periods, with someone else covering.
A rotation works best: one or two engineers per week are project-only and do not appear in the support rota. This makes the capacity real and distributes the disruption rather than concentrating it.
MSP Work Types and How Each Should Be Managed
Work type Demand pattern Management approach Measured by
Reactive tickets Unpredictable Continuous flow, response targets Response and resolution time Scheduled maintenance Predictable, recurring Recurring tasks with owners Completion rate
Sequence client onboarding properly
Predictable shape, variable timing Templated project Time to fully onboarded Migration and infrastructure projects Planned Project with milestones and change windows On-time, on-budget delivery Client-requested changes Semi-predictable Small projects or scheduled work Turnaround, profitability Internal improvement Never urgent Ring-fenced capacity Completion Account and contract review Periodic Recurring scheduled activity
Running Client Projects Alongside Service Delivery
Ring-fence project capacity with a rotation, sequence client onboardings so they do not overlap, and protect the engineer doing the technical work.
Ring-fence project capacity
Decide the proportion — commonly 20 to 30 percent of engineering capacity for a project-active MSP — and protect it with a rotation rather than a good intention.
Publish who is project-only each week so the service desk knows not to route to them. Without that visibility, the protection lasts until the first busy morning.
Sequence client onboarding properly Onboarding is the most demanding project type an MSP runs, and sales rarely sequences them.
Two onboardings starting the same week will both be delivered badly. Keep a forward view of committed onboarding start dates and push back on overlap at the point of sale, when it is still a scheduling conversation rather than a delivery failure.
Protect the engineer doing the migration
Technical project work — a migration, a firewall replacement, a tenant move — requires sustained concentration and frequently happens in a change window.
An engineer interrupted mid-migration is not merely delayed; they may be in a state where interruption causes errors. Treat their project time as genuinely unavailable, and make sure the service desk knows it.
Managing Client Onboarding as a Repeatable Project
Onboarding follows the same shape every time, so template it, run genuine discovery before committing to dates, and define explicitly when it ends.
Template it once
Documentation gathering, asset inventory, monitoring deployment, backup verification, security baseline, documentation of the environment, service desk introduction, first review.
Build it once with tasks, owners and relative dates. Every new client then starts from a complete plan rather than from whichever previous client's notes someone can find. Where the tool supports project templates — as most do, Taskzin included — this converts a repeated scramble into an assignment exercise.
Discovery before commitment
Most MSP project overruns trace to discovery that was too shallow, usually because it happened during the sales process.
Undocumented systems, a server nobody mentioned, an application dependency discovered mid-migration. A properly scoped discovery phase, billed separately, is cheaper for both parties than a fixed-price project based on assumptions.
Define when onboarding ends
Onboarding without a defined end point runs indefinitely, and the client remains in a project state while consuming project capacity.
Define completion explicitly: monitoring deployed and alerting, backups verified, documentation complete, service desk trained on the account. When those are true, the client transitions to steady-state service.
Tracking Profitability Per Client Compare contracted hours against actual, separate project revenue from contract revenue, and review accounts periodically to find the ones losing money.
Contracted hours versus actual
A managed service contract assumes a certain support volume. Some clients consume two or three times what was assumed.
Compare actual hours against contracted assumption per client, quarterly. This is the single most useful commercial metric an MSP can track and the one most often absent.
Project versus contract work
Work performed under a project should be billed as project work, not absorbed into the contract.
The boundary blurs constantly — an engineer on site for a project fixes an unrelated issue, a "quick change" is really a small project. Recording time against the correct item is what keeps the distinction real, which requires time tracked against tasks rather than against clients generally.
Spotting the loss-making account
The pattern is recognisable: high ticket volume, frequent out-of-hours calls, scope creep on every project, and a contract priced years ago.
Review each account against actual hours annually. The conversation that follows — repricing, adjusting scope, or in some cases ending the relationship — is uncomfortable and considerably better than continuing to lose money quietly.
Common MSP Project Management Mistakes
The three habits that cost MSPs most are quoting from optimistic discovery, allowing project work to be interrupted freely, and no formal handover from project to service.
Quoting projects from optimistic discovery
A fixed price based on what the client said their environment contains, rather than on what an engineer verified, is a guess with a number attached.
Charge for discovery, or build a contingency into the quote that reflects the uncertainty. Both are more honest than absorbing the difference.
Letting project work be interrupted freely
Without structural protection, project hours are consumed by tickets and the project overruns for reasons that appear invisible in the project plan.
Rotation and published availability. This is the highest-return change available to most MSPs.
No handover from project to service
The project team completes a migration and moves on. The service desk inherits an environment they did not build, with no documentation of what changed.
Make handover a required project task: documentation updated, service desk briefed, known issues recorded, monitoring confirmed. Otherwise the first incident on the new environment is diagnosed from scratch.
Frequently asked
How do MSPs manage projects alongside support?
By separating the two demand streams structurally — ring-fencing project capacity through a rotation where named engineers are off the ticket queue — rather than relying on intention to protect project time.
How much capacity should be ring-fenced for projects?
Commonly 20 to 30 percent of engineering capacity for an MSP with an active project pipeline, protected by a published rotation so the service desk knows who is unavailable.
How do you scope an IT migration project?
Through a paid discovery phase where an engineer verifies the environment rather than relying on client description. Most overruns trace to discovery conducted during the sales process.
How do you know if a client contract is profitable?
Compare actual hours delivered against the volume assumed when the contract was priced, per client, quarterly. High-consumption accounts on old pricing are the usual source of losses.
Should MSPs use the same tool for tickets and projects?
Tickets suit a service desk tool with SLA tracking; projects suit a project tool with milestones and dependencies. Many MSPs use both, connected — what matters is that project work is not managed in the ticket queue.
How long should client onboarding take?
It varies with environment size, but define the end point explicitly — monitoring deployed, backups verified, documentation complete, service desk trained — so the client transitions to steady-state rather than remaining in project mode.
What causes MSP projects to overrun?
Two things dominate: discovery that was too shallow to reveal the real environment, and project capacity consumed by ticket work because it was never structurally protected.
Binita Ray is a content writer at Taskzin, creating insightful and practical content on task management, team collaboration, productivity, workflow optimization, and SaaS solutions. She focuses on helping businesses, teams, and professionals simplify their work processes, improve efficiency, and make better use of modern productivity tools.
All posts by Binita Ray
Comments