How to Manage Change in Your MSP’s Projects – Expert Advice

We sat down with an expert in change management to get tips on how to successfully manage process changes at your MSP

Introducing and managing change to the way an organization gets work done is an art and a science. Do it wrong and you can spend a tidy fortune only to create chaos and end up going back to what you were doing before. To help you get it right, we sat down with Kathy Boulet. Kathy is managing partner at Pivotal Crew, which is a team of ConnectWise consultants who specialize in mergers, change, and getting the most out of the tools MSPs use to run their businesses. 

Kathy shared her expert advice on approaching change – from start to finish – so you don’t stress out your team, fall behind on work, or end up right back where you started.  

This is what she told us.   

For MSPs that have been burned by failed attempts at change, what steps should they take to approach it differently this time?  

Anytime a project goes badly, do a postmortem to understand what went wrong. What did you fail to do at the beginning to make it successful? In my experience, 80% of the time when a change goes badly, it is because of ineffective training and communication.  Whatever it is, though, it is very important to identify what the issues were that caused the failure and to tie those back to things that you need to do differently next time. 

What are the most common reasons teams resist change? 

This can vary by person, but lack of training or ineffective training has a big impact on resistance to change. The other reason people resist change is that they can’t see why it is happening, how it improves things for them. How you handle those two things works in tandem to make a change successful or not. 

How can you roll out a new tool without disrupting the current work? 

The key here is to take it slow and communicate thoroughly.  

The thing that gets people anxious is not knowing what the change means to them. When I’ve seen changes go poorly it is usually because leadership is trying to go too fast and not taking communication seriously.  

Without buy-in from your teams, change can be very disruptive. You might end up losing employees and it could have a negative impact on customer satisfaction. But forewarned is forearmed. Communicate what the business is getting out of the change. Let people know how to raise objections or issues. Make it clear who they should tell about problems and how those will be identified and solved. 

Now, can you implement a change with no interruption? That depends on how big a change we're talking about. In the context of someone implementing Moovila? That's a brand-new tool and it is completely different.  

In that case, I suggest that you tell your teams that you are evaluating this tool three months before you do anything and make it clear what you hope to get out of it.  

You are bound to have somebody who thinks it’s painful to use ConnectWise for project management and thinks this will be great. But somebody else will feel that ConnectWise might be painful but they already know how to use it. 

After that, training is super important. Many companies assume everyone will be able to figure it out and all they have to do is send an email. That creates problems. One email is not going to drive this solution home. You need plenty of training. 

In fact, if you are implementing a new tool, a buddy system is great. Have somebody on site who is an expert or somebody on the team that's already used it. Maybe roll it out to a small group first and let them be your buddy system when you roll it out everyone.  

 Is there a right way to communicate a new process? 

When implementing changes, tie it to the outcome the business is trying to accomplish. If you have KPIs and are not hitting your goals, perhaps you are solving this by adding a step into the process. Tie the change to a measurable outcome people have heard about. This is critical.  

If you're looking at project management, for example, and the tool you are currently using isn’t mature enough to offer efficient resource management, explain that you found an application to help solve that. Let the people who do projects know that you're trying to solve the problems they've been telling you about. But let them know early. Let them know during the evaluation stage. That lets them get some skin in the game. 

The second part is letting people know that they get to participate in the evaluation. This communicates that you are considering their input. 

And once the decision is made, be reasonable about the implementation timeline. Rely on your providers to help you with this. They know what training is available and how long it takes to go through it. 

You also have to marry all of this with who your team is. People who have been in their roles for a long time might be averse to change. They have figured out how to work around the problems they see in the way things work, and while they are problems, they know what to do by habit. If they can roll with changes, you might be able to shorten the timeline. If they are invested in the way they are currently doing things, you will need more time. 

Is there a wrong way to communicate change? 

Don’t have your head in the sand and pretend change is easy. It isn’t. And the larger the company is, the more people whose processes you are impacting, the harder the change will be and the more important communication and training will be. 

If you are assuming people will understand why you are making the change, it won’t go well. Engineers and technical resources need to understand what it will mean to them. Employees usually haven't owned a business. They don't understand that sometimes decisions need to be made because it will have an impact in another part of the business – outside their day-to-day work life. Explain!  

Also, if this process happens over a few months, you have to manage it in stages of seriousness.

During the first month, if there are problems with the way people execute the work, fix it for them and communicate what you're fixing. In month two, stop doing that. Send it back to them to fix the problems themselves. If you are still seeing the same problems in month three, it is time to start talking seriously about why this is happening and to make it clear that this is a requirement for the job. This is a place where a lot of companies slip up. They allow people to keep doing it the old way and don't initiate a hard stop that says we're doing it this way from now on.  

 How do you know your change is making a difference? 

At the very beginning, when you're starting to evaluate any major change to your applications or processes, identify what you hope to accomplish and what metrics will allow you to see if it's working. 

This could be a software question. Does the software you are considering tell you that people are using it or doing things correctly? If you are trying to improve your ability to manage projects and get better resource management, for example, the end result you are looking for is better results in the metrics you identified. Identify at the beginning what you are trying to accomplish and what you will use at the end to identify if it's working. 

This might not necessarily be a KPI. You might be looking for better reporting, better resource allocation, improved capacity understanding, and a better view of what's coming down the pipe. ‘Do I have data I can trust, that will help me make decisions?” 

Do you have any advice for project managers who are implementing automation or AI-driven tools into their workflows?  

I don't think that there's any risk today of people in the MSP business being replaced by AI. AI often gives the wrong answer, or wrong instructions. But it will still cause fear among your team. 

You can counter that by demonstrating that you understand their pain points. If they can spend more time doing technical stuff instead of writing things down or making sure that something happened afterwards, for example, or if you are implementing automations that can identify problems, capacity conflicts, or resource conflicts. Explain the advantages.  

Make that explanation meaningful to the individual so they will have less anxiety about it taking over their jobs. If automation takes away pain points, they will see it as a bonus.  

Can you offer some practical tips to help MSPs get people invested in using a new project management system or methodology? 

You will meet resistance to any change, even when it’s clear the new way is better. People have a comfort level with the way they are doing things already. To get past that, make sure you understand why you're making the change so you can drive home the key outcomes. Make it clear that you aren’t merely trying to do something different, that you have real reasons.  

Next, find a way to make people feel they have input into this decision. You don’t have to give away the decision-making, but you do need to gather feedback and take it into consideration.  

This next piece is to focus, when you're talking to your teams, on the benefits of the change at an individual level. You need to be able to tell this technician or that project resource what will be better for them when the change is implemented, and everyone is past the learning stage. 

If you have a small company, this is easy. Talk out the problem and the tool you’re looking at to solve it. Ask about people’s angst and how to solve or mitigate it.  

When you have a larger company, you can’t talk to everyone. You have to speak to a representative from each team and – to get buy-in – it’s best if each team elects their spokesperson. When they choose the person, based on whatever criteria is important to them, they will – hopefully – feel their needs are being respected.  

This sounds like high maintenance but, in larger companies, you have to think about communication strategies. The communication piece of implementing change is very important, especially if you're upsetting the apple cart for a particular part of your business. 

Are there emerging technologies that you think will influence how organizations approach transformation? 

AI is on everyone's lips. Every software as a service out there is trying to tie AI to their system and people are anxious about AI taking over their jobs. Companies have got to get ahead of that. If you bring in a tool and you know it's got the word AI attached to it, you have to address that: “I'm not bringing this in so I can fire half of you.”  

Call out immediately what you are using it to achieve and tie that back to the individual so they can understand the improvements they will see personally.  

The communication part gets more important when you're using emerging technologies. And you need a feedback mechanism so people can tell you how well it is working. If AI is supposed to be doing something and it doesn't work, how do people tell you?  

If your focus is growing your business without having to hire as many people, because automation can make the existing team more efficient – versus trying to reduce the team you have – that is a goal that can be articulated in a meaningful way to technicians, managers, executives, and ownership in a positive way. 

Ready for more from the team at Pivotal Crew? Check out their new Proactive Quarterly Audits offering. For more help with project management for MSPs, check out the Moovila Blog.