A Q&A with Dean Trempelas of Empath on How MSPs Can Get Better at Managing Projects

As the head of MSP success at Empath and someone who has mastered projects to drive his own MSP to success, Trempelas is an expert on managing MSP projects.  

Dean Trempelas is the Head of MSP Success at the online MSP learning platform Empath. Before he took up teaching other MSPs to master project management, he had the unique experience of helping his team grow a struggling MSP to one with over 300 employees and over $55 million in revenues, mostly by becoming expert at running efficient, predictable, and profitable projects.  

We sat him down, pelted him with questions, and convinced him to share his secrets. This is what he told us.   

Q: What are the key elements that define a project and how can MSPs classify and structure their projects more effectively? 

First and foremost, you cannot treat a project at an MSP like an internal project. MSP projects involve external stakeholders. If I'm doing a project for you, we don't have the same boss. You work for an entirely different entity. Also, projects at MSPs have billable components because we are doing them – hopefully! – for profit.  

MSP projects have more in common with a project that a trade – plumber, contractor, or electrician – might do than they do with the projects in much of the IT space. 

This is why scoping is so much more important for an MSP than for someone doing agile or lean with an internal team. Time tracking is more important, too.  

But the single most important element of MSP project management that most of us do not get right is communication. Many MSPs do all this wonderful work and somehow fail to tell the client about it. 

Q: What tools do MSPs need to deliver a project successfully and hold it accountable?

Answering this question was a light-bulb moment for me: You do not need any tools in your tech stack to deliver a successful project. You need a process – a consistent process. But you don’t need tools. 

You can lay out what's supposed to happen, the expectations, the order the work will happen in, where to ask for money, and what the client can expect from you without tools. 

In fact, that’s where you have to start.  

Don't start with the tool and try to find a way to use it. Figure out what you want to deliver and the experience you want to give your clients, then layer in the tools you might want to help you do that.  

If you can consistently do the same thing, even with a minimum tool stack, you are far more likely to meet the client’s expectations and delight them than if you do some things well and others below spec. 

Q: Scope accuracy is a source of anxiety for MSPs. What are some common mistakes and how can MSPs improve their scoping process? 

The most common mistakes that I see?  

• Overpromising deliverables without truly understanding the work involved. 

• Ignoring dependencies between phases or milestones. 

• Writing vague SOWs that leave a lot to interpretation, which is often a symptom of the first mistake. 

But it all comes down to the same problem.  

Here’s an analogy: If you go to a McDonald's anywhere in the world, you could probably navigate the menu options, in any language, because the product is consistently executed the same way everywhere. They have scoped each burger and the extras and options and created a menu for customers to choose from. 

I’m not saying you want to deliver McDonald’s-level service but If you can approach projects like this, your scoping will improve. 

Many of your projects are the same thing – with tweaks. But MSPs tend to let clients stare at a limitless menu while waiting for them to decide what they want. This makes it hard to write a scope.  

If you define each product, though, it's easy to ask a couple of qualifying questions and make a recommendation to the client. If they want a change later, that would be a change order. That is how you manage scope and prevent scope creep. Defining the product is much easier for the customer as well.  

Everyone has experienced this the wrong way and the right way. If you have had any anything custom done – a kitchen or landscaping – you've met the two types of contractors: The one who overwhelms you with choice and the one that does a wonderful, subtle job of guiding you to the right decisions where you are left feeling like they saw your vision. No, they didn't. They guided you to their vision, which aligned with your expectations. 

Q: You have said that MSPs don’t think critically about the level of resources needed for each task. How can they do this better? 

The MSP I helped grow to $55 million in revenues was sandwiched between two big cities. That meant that everyone we hired who could drive would get experience with us, leave, and get a $20,000 raise. I could not keep high-level people. One of the rocket fuels for our growth was the moment when I realized I couldn’t keep hiring $120K a year, tier-three people and looked for a way to use people who were a year out of school to achieve the same result. 

It is not an instantaneous journey. But if you consider how much of your projects can be done by level ones, you're going to find that – for most projects – it is something like 60% of the work, especially if they're following a process. You can do this with a high degree of competence and deliver high-quality output. 

That is a helpful mindset to get into because not only will your profitability be greater and you will be able to hire people who are more plentiful, it'll cause you to start thinking more practically about how much you over deliver – a prevalent MSP problem. 

Q: You said that you break projects down based on what can be done in the office vs. what must be done on-site. Can you walk us through how and why you do this? 

Let me use a network refresh as an example of a task that we know has some low skill labor and is also the type of project we tend to give to a high-level person to go on site to figure out and deliver.  

Labor is your highest opportunity cost. It is the most expensive thing at an MSP. I realized a lot of work – even something as complex as a network refresh – could be done by a low-level person. But to make me feel comfortable with them doing it, I wanted to supervise them. And where can I best supervise that low-level person? In the office. 

That got me wondering how much of this work I could do in the office before I had to bring it to the client site, and I realized it was quite a bit. You set it up and bring it over there and, kind of, plug it in.  Then I realized that if I made detailed instructions for exactly how to plug it in, I didn’t even need a high-level person to go do that. Maybe I could send the account manager, along with a lower-level person. The account manager brings donuts and schmoozes the client while my level one or level 1 1/2 tech is racking equipment and plugging it in using color-coded wires and following along on a chart I made. I might need a tier three person on the phone, back at the home office. But that tier three can also be doing other things. 

Q: How do you see the role of automation and AI evolving in MSP project management? Can these technologies help address some of the common project challenges you’ve highlighted? 

I hate AI for service delivery. But if I'm being pragmatic, and if we think of AI and automation as the ability to take data and make informed decisions, it can be a big help. It might say, ‘You've done other projects and here is some data to give you a check on timeline or scope.’ Or perhaps, ‘Hey, the last 10 times you installed a server, you went 40% over scope. There is no way this scope is accurate.” 

That's a great use case. 

Status updates, dependencies, making sure those things stay connected and up to date. Prompting the PM to check for those things. Being able to look for scope creep – either through keyword identification or ticket creation. These are also great use cases. 

And most importantly, it’s great for communication. All our ticketing systems have communication automation in them. It all works. Use it! Clients don't care if the communication is automated as long as it's relevant. 

Q: For MSPs that struggle with project completion and accountability, what are some practical steps they can take to improve that? 

You have to get rid of set-it-and-forget-it syndrome with projects. Projects need active ownership. A project is like a child, a pet, or a plant. It needs to be watered, cared for, and tended. 

You need checkpoints, milestones, phases. Break your project into logical chunks that makes sense for you and the project stakeholders. Have accountability loops that allow you to reassess along the way. If you're doing billing, whether you're billing by phase or recognizing revenue as you move through the project, that should, at the very least, be a checkpoint to take stock of where you are. 

Q: What are some underrated or overlooked project management best practices that you believe more MSPs should adopt? 

Put a phase at the end of every project – separate from the billable scope – and call it something like project support. Use it to track every support ticket that is because of the project, part of the project, or because something about the project was improperly installed. You want to catch all of that. 

Track those things for, let’s say, 30 days after the project. You will be glad you have that data when you go back and scope the next project like that. But MSPs often don't do this because support goes to the support department and is no longer tracked with the project. But it's important. Maybe, for example, you spent 20 hours helping the customer because you didn't explain how to log into their new e-mail. Now you know that explaining how to use email should get added as a task in that type of project going forward.  

Q: Are there underrated and overlooked project management best practices you think MSPs should engage in? 

I would advocate for some sort of client sign-off process at every phase. It might seem a little clunky at first, but it'll help you not let projects drag on where the client is not responding. If the client doesn’t sign off, you pause right there. If you decide to sidestep your own rule, and continue without that sign-off, that is, at least, a choice.  And if you aren’t doing a project postmortem, start doing them. This shouldn’t just be about what went wrong or how do we avoid it next time. Ask what went well, what surprised us, and what delighted the client.  

Q: If you could give one piece of advice to an MSP that constantly runs projects that go over budget or over time or are under-resourced, what would it be? 

You might think you are estimating projects. You’re not. You're guessing. Stop guessing. 

If your project budget is based on wishful thinking instead of real numbers, you might as well be playing the lottery. How can you drive yourself to efficiency if your process is to ask your engineering department ‘How long do you think this will take?’   Even if everybody on your team is top-tier talent with the best intentions and never wastes a minute, it's not possible to make money in any predictable way doing that. 

Check out the Moovila blog for more learning resources on managing projects at MSPs. If you are looking for in-depth learning tools to help your MSP master projects, Empath can help you delve deeper and skill up. For more content from Dean, follow him on LinkedIn.