Many Managed Service Providers (MSPs) struggle to make solid profits with their Project Practice. In looking at benchmark reports and talking directly to MSPs it’s clear that many don’t make the money they should. You should be making a healthy profit on your projects, and if not you’re leaving money on the table.

My name is Adam Hannemann, welcome to Ramblings of a Geek. I’ve been in the MSP space for the better part of a couple of decades and I’ve spent quite a bit of time on the project side of things. Managing and upgrading the margin coming from your project team isn’t easy, but it can be done.

Let’s talk about seven ways you can manage projects better to get more from your project practice. There’s a few things to juggle here, but it can be done.

Manage Your Pipeline

The first thing that is vital to a healthy project practice is having a solid project pipeline. You must keep enough projects ready for your project team to work on. The first step is to know your project capacity. When you know your capacity you can extrapolate what you need in your backlog to keep your techs billing.

If your project team can reliably close $15,000 in projects per month then you need at least $30,000 worth of projects in your pipeline.

You keep your pipeline full by properly building your Account Management practice. Keep your clients’ technology roadmaps up-to-date and actively drive those plans forward.

Properly Scope Your Projects

Scoping your projects well is one of the biggest drivers of individual project profitability. I have lost count on how many times I’ve seen a project that was under scoped that crashed and burned. Scoping projects well is so important that I could probably make a whole video AND blog post talking about this.

Anyway, as you scope projects, you will screw up. Learn from these screw ups and adjust your scoping accordingly. Give yourself a LOT more padding than you think you need, and make sure that you build in time for managing the projects themselves.

The key here is to learn from every single project you complete in your MSP. If you scoped it well, cool! Learn what you did right and do more of it. If you screwed up, crap! Learn what you did wrong and do less of it.

Change Orders

When a project has a scope and something needs to happen that is outside that scope you MUST perform a change order. Building contractors are fantastic at this, but Managed Service Providers often aren’t.

When something changes that’s outside your control someone should pay for it, and it’s NOT you. Not only does a change order often require additional money, but they often require additional time. You need to be careful to not let a change create a big backlog in your projects.

Often the best resource to manage these change orders is your Project Coordinator or Project Manager.

Project Engineer vs Project Manager

It is rare to find someone in your project team that can handle managing the project, communicating with the client, and doing the project work. Good Project Team Members can do two of those three tasks well, but often not all three.

I was pretty good at all three things individually, but I would routinely drop the ball on one of them when trying to manage all three. This was even more likely to happen if I was working on several projects at once.

I believe it’s a best practice to have a Project Coordinator or Project Manager manage the tasks and communication and have your Project Engineers do the technical work. This allows your team to focus on their strengths and minimize their weaknesses.

Manage the Number of Open Projects

Frequently MSPs end up trying to work FAR too many projects at once. I’ve seen plenty of MSPs try to work 10-15 projects per engineer at once. That’s too many to move anything forward.

Ideally the number of projects active per engineer at once is one. That’s not especially realistic, so it’s reasonable to have a cap of 3-5 projects at once per engineer. Fewer is better, but the goal should be to work a project to completion (and really complete it) before adding new projects onto their plate.

Managing Project Engineer Billable Time

One of the struggles I had in my most recent project practice was that my Project Engineers were awesome human beings. Now, that’s not the struggle exactly, but what I ran into was that my Service Desk would routinely ask the Project Team for help. My Project Engineers, being the awesome humans they were, wanted to help their teammates out, so they did. The problem was it slowed down project progress which slowed down our ability to bill our projects out.

They had a target to bill 6.5 hours per day (~80% of their day). Once I realized why we were having issues closing projects in a timely fashion we reset the expectation. Project Engineers would take 8+ hours per week helping the Service Desk. So, we said that out of their 6.5 billable hours per day they had to bill 5.5 on projects and they could spend up to 1 hour helping the Service Desk. This changed things almost over night.

Properly manage the expectations of your project team and your project completion rate will thank you.

Perform a Project Post-Mortem After EVERY Project

How do you tie all of the above together? Easy, perform a Project Post-Mortem after every project. We would routinely do these every other week to dig into what worked well and what could have gone better for every project.

This is where we would dig into SOW issues and fix our quoting and scoping issues. This is where we would identify opportunities for automation, better documentation, and other ways to build efficiencies for the team.

Sometimes these meetings would be very quick, and sometimes they’d be more drawn out. They were always valuable, so don’t skip them in your project practice.

Managing your Projects and your Project Team well will drive revenues and margins up. Do the smart thing and pay attention to these pieces that have a direct path to driving your margins up.


Discover more from Ramblings of a Geek

Subscribe to get the latest posts sent to your email.

By Adam

Leave a Reply

Your email address will not be published. Required fields are marked *