IT Project Management For Small IT Teams And MSPs

IT project management is planning, assigning, and controlling one-off technology work so it finishes on scope, on time, and on budget. For a small IT team or MSP, that means an office move, a Microsoft 365 migration, a device refresh, or a network upgrade, run between support tickets.

Below: the four phases, scope and change control, tasks as tickets, time logged against the project, a project budget template, a worked migration, and a closeout checklist. It comes from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) a small IT team can run alone. Two founders who ran their own MSP have built it since 2001.

What Is IT Project Management?

IT project management covers software development, hardware installations, network upgrades, cloud and virtualization rollouts, data projects, and new IT services.

For a small team, IT project management needs a narrower line. A support ticket restores something that already worked. A project delivers an agreed change: it has an outcome someone accepts, enough tasks or dependencies to need a plan, and its own approval. One MSP owner on r/msp sets the line as a policy: "Support is the work required to keep the existing environment running. It restores the status quo. Projects are any work that changes the environment or adds to it."

Their billing rule: "If it didn't exist yesterday and you want it to exist today, that is billable." Yours may differ: a new user or a standard laptop can sit inside the agreement. The agreement decides who pays; the project test decides what needs a plan.

Why IT Project Management Matters When You're Also Running The Queue

The riskiest project is the one nobody called a project: it has no scope, no budget, and no approval to stop it growing. Scope creep in project management means "the gradual expansion of functions or adding features, functions or other deliverables beyond a project's original parameters."

Weak change control is a named cause: "Without those controls, scope creep takes root." The money at stake is mostly time. "Labor is typically the largest project expense," and a change that adds time raises the cost.

The r/msp owner above found it the hard way: "I was letting clients sneak entire infrastructure upgrades into support tickets." Once they counted the time on those mini-projects, their flat-fee contracts were losing money.

Internal IT pays in a different currency: the project eats the hours the queue needed, and tickets wait. IT project management lets you see that trade before you make it.

Types Of IT Projects And Project Management Methods

Most IT projects a small team runs fall into five types, each with its own trigger and trap.

A device refresh also raises purchase-to-disposal questions; our guide to IT asset lifecycle management covers them.

The method is the second choice. Project management methods differ mainly in how much they plan before work starts:

The adaptive approach is "ideal for software development projects." For most IT projects, a predictive plan with a board fits a small team best.

What You Need Before You Start

On a team of two to ten, IT project management runs on five basics:

1. A written line between support and projects. Write down which requests the recurring fee absorbs and which ones get their own price. The scope clauses are in our managed services agreement guide.
2. A project rate. Your hourly rate for project work, and whether you sell fixed price, hourly, or both.
3. One place for tasks and time. Tasks, hours, notes, and files on the client's record. A spreadsheet works until you start reconciling tasks, hours, and invoices by hand.
4. A named client contact for the project. One person who approves scope, changes, and acceptance.
5. Your last three projects' hours. Rough actuals beat a fresh guess.

The Four Phases Of IT Project Management

The formal model has five process groups: initiation, planning, execution, monitoring and controlling, and closing. On a team of two to ten, the lead technician is often also the project manager and monitors the work while doing it, so four phases are enough.

1. Scope the work

   Write what will be delivered, how the client will accept it, and what's excluded. A scope statement "explains the boundaries of the project." Get it approved before anyone books a site visit.

   Example: "Move 20 mailboxes and shared files to Microsoft 365. Accepted when every user sends and receives mail there and opens their files in OneDrive. Excludes phones and the accounting app."

   Common mistake: scoping by outcome only ("move to the cloud"), so every later request looks like it was always in.

2. Plan tasks, hours, and budget

   Group the scope into work packages, split each into tickets a technician can finish in a day or less, and put hours on each. Add expenses and contingency: that's the estimate you'll compare against actuals.

   Then plan around the queue. Decide who stays on support, how many hours a day the project technician really has, and which tasks block others. For a cutover migration, the domain must be verified first.

   Example: seven work packages, 39 hours, 6 hours of contingency, and site visits. One technician gives the project four hours a day; two keep the queue. See the budget template.

   Common mistake: leaving out project management time. Status calls and notes are real hours.

3. Execute and track against the plan

   Work the tasks, log time against the project, and compare hours used with hours planned every week. In project management terms, this is monitoring and controlling: "time, cost, scope, quality, risk and other factors."

   Example: by Wednesday of week 4, device setup has used 9 of its 10 hours with six users left. You tell the client that day.

   Common mistake: checking the budget only at the end, when an overrun can only be absorbed.

4. Close and hand over

   Closing confirms the work is complete and approved, and that "ownership is transferred from the project team to operations." For an MSP, operations is your own support queue.

   Example: written acceptance from the office manager, updated documentation, final invoice, and a 15-minute review of estimate against actual.

   Common mistake: leaving the project open for months while "small things" keep landing on it.

Scope And Change Control

Project scope is "the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines." The written version, the scope statement, also guides "decisions about change requests during the project."

Three parts do most of the work on a small project:

• Deliverables: what you hand over and by when.
• Acceptance criteria: how the client will judge it done.
• Exclusions: what's not included. "Objectives and tasks not listed in the scope statement should be considered out of scope."

One r/msp member's advice on a 30-hour migration quote: "Make sure your scope is nice and detailed and broken down to justify the hours." Our guide to MSP proposals covers the document around the scope.

Change control is the part of IT project management that protects your margin. Each change request "must be evaluated for its impact on the project." Five steps are enough:

1. Log it. The request becomes its own ticket on the project, in the client's words.
2. Estimate it. Hours, expenses, and the effect on the end date.
3. Get written approval. An email reply counts. A hallway yes doesn't.
4. Update the plan. The approved hours join the budget as their own line, so the original estimate stays readable.
5. Record the no. A declined request "is also documented and kept in the project archives."

One r/msp member names the point of the gate: it should "allow that COST conversation to happen BEFORE the work is done." Approved change requests then "must be communicated to the appropriate stakeholders at the right time."

Tasks As Tickets And To Dos

A project plan only helps if the work shows up where technicians already look. On a small team, that's the ticket queue. So run project tasks as tickets, each with an owner, an estimate, and a due date.

Size each ticket so one technician can finish it in a day or less. A 20-seat migration might have seven work packages matching the budget lines, with the big ones split: device setup becomes four tickets of five users.

Use To Do lists for repeatable steps inside a ticket. Per-user setup is the classic case: sign in, Outlook profile, OneDrive sync, printer, device noted in documentation. The ticket carries the hours; the checklist proves each user got every step.

Then put tickets and projects on one Kanban board: to do, in progress, waiting on client, done. Read the "waiting on client" column every morning.

Project notes belong on the project, not in a separate app. One r/msp member running client projects named the split they wanted to end: "The main issue with it is the project memos and temporary documentation." Documenting "all assignments, expectations, changes and progress updates" is also how you defend scope later.

Time Logged Against The Project

Every hour of project work goes on the project, from every technician, the same day. That includes travel, status calls, and the half hour spent finding the old server's admin password. Hours logged later are hours guessed.

Count the project manager's time too, even when it's the same technician. One r/msp member described moving from a flat markup to line items. "I was previously taking the project labor total then adding 20% to be our 'project management budget', then switched to adding time for individual tasks …"

Logged actuals are also your estimating library. Another member's advice for new project types: "Make it technically science by writing down your guess, and how long it actually took."

Keep unbilled hours visible too. "Document time spent on 'non-billable' work, and give them regular reports. Let it be their decision," wrote one member about clients used to free extras. Our guide to billable hours tracking covers logging habits for the whole team.

A Simple Project Budget Template

A project budget needs four columns: line, estimate, actual, and variance. Costs include "materials, pricing, services, facilities, software licenses and other expenses attributed directly to the project." For most IT projects, labor is the line that moves.

Example: the 20-seat Microsoft 365 migration from the phases above, at $150 an hour, with one approved change. The table is the budget for billable work and expenses; Microsoft 365 licenses run on the client's own subscription, outside it.

The client approved $6,810; the change raised the budget to $7,110, and the work ran $480 over that. Contingency absorbed 6 of the 9 extra hours, and 3 sat in device setup. The shared mailboxes aren't an overrun: they came through change control.

To reuse the template, keep the rows as your task list and add one row per approved change. Never edit the estimate column after approval; the variance column is your next quote's lesson.

On a fixed price, you can't bill the extra hours, and the technician time behind them comes out of your margin. On hourly work, they're billable only within the terms you agreed, such as a cap, and not when the overrun fixes your own mistake. One r/msp member put the fixed-price risk bluntly: "Doing fixed fee on an unknown process is the place profits go to die."

Risks And Communication

A risk register records each risk with its probability, its likely impact, the response, and "the owner of each risk." On a small project it fits in four rows under the scope statement.

A communications plan addresses "who will need what information, when the information is needed and what modality is best." For a small project: a weekly status email to the client contact, a notice to users before the change, and a welcome note after it.

Keep the weekly email to four lines: done this week, next week, hours used against budget, and what you need from them. Bad news goes in the same email, early. As one r/msp member put it: "If you're going to go over on hours let them know as early as possible."

Closing And Handing Over

Closing ends with a short report on "issues that were addressed and lessons learned" and recommended follow-up steps. For a small team, the checklist below does that job.

If the project brought in a new client, the MSP client onboarding checklist picks up from here.

Best Practices And Common Mistakes

A short pre-flight check for IT project management on a small team:

Worked Example: A Small-Office Microsoft 365 Migration

Example: a 20-person accounting office runs mail on an old on-premises Exchange server and keeps files on a shared drive. The scope is the one from the phases section: 45 hours and $60 of expenses. Microsoft supports cutover migrations of up to 2,000 mailboxes but recommends 150 or fewer, so a cutover fits.

1. Week 1
   Scope

   Discovery visit, mailbox and file sizes, scope statement with exclusions. The office manager approves it by email.

2. Week 2
   Plan and prepare

   Tenant, domain, and licenses, with work packages split into day-sized tickets. You lower the MX record's TTL to 3,600 seconds or less, as Microsoft advises before migrating. Users get a notice.

3. Week 3
   Files and cutover

   The project gets four hours a day in total. Within that limit, the file move to OneDrive and SharePoint takes 10 hours, Monday to Thursday. Mailboxes migrate Friday night, after queue hours. The client adds two shared mailboxes: a change request, 2 hours, $300, approved.

4. Week 4
   Devices

   Day-one support and device setup share the same four-hour daily limit, Monday to Thursday. Device setup, five users at a time, takes 13 hours. On Wednesday it has used 9 of 10 hours with six users left, and the client gets an update.

5. Week 5
   Training and close

   Training on Monday. The batch is deleted once every user is on the new mailbox and its Last Synced Time is later than the start of direct delivery. Licenses checked, written acceptance, documentation, final invoice.

Device setup ran 3 hours over because six laptops needed updates before Outlook would set up. The Wednesday update said so, with the new estimate. The final invoice was $7,590 on hourly terms, and the client had already seen every line that moved.

The lesson is one number: device setup took 13 hours for 20 users, or 39 minutes a user, not 30. The next migration estimate starts there.

How To Measure It Worked

Four numbers show whether your IT project management gets better. Read them at each closeout and once a quarter:

1. Estimate accuracy. Actual hours divided by estimated hours, per line and for the project. In the example, device setup came in at 13 of 10 hours (130%) and the original scope at 48 of 45 (107%). With the approved change, the project ran 50 of 47 (106%).
2. Changes approved against changes absorbed. Requests through change control versus requests done for free. The second number should fall.
3. Days from acceptance to final invoice. A project isn't paid until it's billed. Aim for the same week.
4. Tickets in the 30 days after handover. Many tickets on the new system point to gaps in testing, training, or documentation.

IT Project Management Tools: What To Look For

A project plan can live in tools "as rudimentary as an Excel spreadsheet or as advanced as Microsoft Project," and the spreadsheet "is useful for simple projects." Teams that manage projects in spreadsheets hit the limit when projects overlap with the queue: tasks in one place, hours in another, invoices in a third.

When you compare IT project management tools, check six things:

• Projects on the client record. Tasks, notes, files, and hours on the same account as the client's tickets.
• Tasks as tickets. Project work in the queue technicians already watch.
• Time on the project. Logged from the ticket, a timer, or a phone, the same day.
• Budget and hours together. The budget and the logged hours on the same project record.
• A path to the invoice. Project hours reach the invoice or accounting system without retyping.
• A board view. What's moving, what's stuck, and what's waiting on the client.

Where To Start

Fill in the budget template for your next project before work starts, then again at closeout. Kept for every project, that table does more for your next quote than any method.

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.

All Articles