“Change management” is a term that gets thrown around in government and large corporations, but it’s a challenge that all companies face.
Managers are trying to find tools and workflows that maximize productivity, but employees don’t always see it that way. The larger the organization, the more pressing the challenge. The only way to keep pace with a growing company in our fast-moving world is to get the two parties on the same page.
This is something that we run into often here at Teamwork.com. Someone signs up, gets excited about all the features in Teamwork Projects, but then has a hard time getting their team to move over from another tool – even when the benefits are clear. It’s a classic business problem and there are tried-and-true ways to address it. Here are five things we’ve learned about getting your team to change when they don’t want to.

1. Understand and address the fear of change

Humans’ fear of change is deeply rooted in behavioral psychology. When your support team resists moving from one helpdesk tool to another, it’s not because they want to slow down the business or frustrate the customers. It’s simply because there is some risk involved in venturing into the unknown. As a manager, it can be difficult to accept that changing software triggers our survivalist instincts. You can accommodate for this by making an extremely practical case for the change.
In an article published on the University of Texas Health Science Center website, psychologist A. J. Schuler writes that, “when the rational mind is engaged, the emotional mind (which is typically most decisive) can begin to grapple with the prospect of change.”
He recommends selling new ideas on the basis of logic, not ideals. It’s important to understand why your team fears change and never forcing it on them. In the helpdesk example above, a manager could state the case for the move, draw up a side-by-side comparison of the two tools and create a detailed plan for the migration.
When your team sees that it will only take five minutes to learn the new ticketing system and it will save them a few hours each week, it’s much easier to get buy-in.

2. Align tools with strategy

Tools can help you execute an already-strong strategy, but they can’t compensate for lack of vision. In our experience, the teams that use tools like ours (Teamwork Projects, Desk and Chat) to solve a specific problem are more efficient than the ones who aren’t sure exactly what they need.
This may sound obvious, but new tools have an odd affect on our brains. Novel discoveries release dopamine – the same chemical that makes us feel great about going for a run or falling in love. When you discover a new tool or technology, you might feel overwhelmingly excited about it. Your team’s first instinct might be to resist, leaving you with mixed emotions and a sense of personal defeat.
Be careful when this happens. Emotions lead to bad business decisions. Smart decisions start with a cohesive, transparent strategy – that’s how you get buy-in from your team too.
If you agree on a project management strategy like agile development, for example, it’s easy to find a tool that fits the bill. But imagine finding a new agile tool and trying to move your team without first agreeing that agile is even the right workflow. It will never work.
Think of your strategy as a positive constraint. It’s much easier to make decisions about the tools you use and to get buy-in from your team when the strategy calls for it.

3. Leverage influence, not authority

A common mistake that teams make is having their early adopters lead the migration to new technology. But there are two parts to every software change – the technical migration and the cultural change. You need to put the right people in charge of each process.
As most managers will attest, it’s significantly harder to manage the emotional and psychological aspect of change. Your development team might be excited about a new piece of technology, but if they have no influence over your company’s culture, you can’t expect them to lead the way. It’s important to get your company’s most influential people involved early.
Like consultant Michael C. Mankins told the Harvard Business Review, “Don’t just pick the geeks – those who are most interested in technology. You want people who are able to work horizontally across the organization and who have good communication and networking skills.”
Getting the endorsement of influential leaders in your company is one of the keys to making change happen quickly and efficiently.

4. Run a pilot

Inventor Charles F. Kettering once said that “A problem well stated is a problem half-solved.” You want to be sure that you understand the problem you’re trying to solve with new software before you start testing. This is why no software should ever be implemented without a pilot.
Pilots accomplish two key things. First, they prevent you from fully migrating to a tool that might not work. Second, it proves to your team that you’re committed to solving the problem, not just changing software. If it works, your solution earns credibility. And if it fails, you’ve dodged a bullet.
The issue that most teams face when running a pilot is that they don’t have a baseline to measure against. A pilot works best when approached with the scientific method. You develop a theory, then test a control against a variable. If you understand what exactly you’re measuring, the decision to switch (or not) will be easy.
 
5 ways to get your team using new software

Image via Carnegie Melon (Conducting Effective Pilot Studies)

During a pilot, we recommend seeking out objective data (tasks accomplished, output, etc.) and subject feedback (ask your team for ongoing, anecdotal feedback).
Pilots are a low-risk way to validate your theories and fail fast. It’s better to make a small investment and iterate than it is to make a big one and backtrack.

5. Let people learn their way

Once you’ve decided to make a change, the onboarding process can begin. And if it’s not managed well, you risk confirming the fears of resistant team members.
We encourage you to let people learn in their own way. At Teamwork.com we know that some people are happy to read a knowledge base doc, others prefer watching tutorial videos or webinars, and still others like to sit down with an expert. We make all of these available and it’s helped our customers onboard their teams faster and with less frustration.
If you’re thinking about rolling out new software or struggling through a migration as we speak, download the Teamwork.com How to Choose and Rollout a New Saas Product Checklist