Is it harder to deploy an enterprise system when you aren’t co-located?
Of course.
But, it is much more common than you might think.
If we think of deploying a system to a small business where everyone is in the same building, then communicating and encouraging use of the new system is easy to imagine. As the new system is designed and configured, the people doing that work are walking along the same corridor as the people who will ultimately use it. The shift from the old to the seems that much more natural.
When a team is not co-located, we have to think a bit differently to ensure that the implementation of a new system and whatever changes in business processes result from that change are accepted by everyone.
With so many organizations having shifted to working remotely or even to a situation where many will work from home, you might encounter challenges you aren’t expecting. For many years we have worked with organizations who did not have everyone in the same building or even in the same country who deployed project management and our own timesheet system TimeControl. It may be worth taking some experience from those who have implemented remote and out-sourced teams to see how you can get people on board with your new enterprise system.
Let’s take a look at various challenges in a system deployment and how to attack them.
Culture
First, let’s look at the big one. Corporate culture can be an enormous challenge. It’s the “We’ve always done it this way before.” challenge. It’s a truism that change causes upset. That’s true whether you all work in the same office or are all working remotely. So, how do we encourage people to accept the change in the “way we’ve always done it.”?
Communicate
Communicate, long in advance, of what your intentions are. There are so many ways to communicate so that people can start thinking about what is coming soon. This may result in some push back from those who abhor change, but pushback from that source is coming no matter what so at HMS we’ve always found it better to get those people thinking about these changes earlier than later. Communication can be through newsletters, blogs, video stories, social media, email or whatever way you might normally communicate with your team. Remember that these days your team might include those outside your own company as we consider contractors and others who are affected.
When you communicate, one thing to keep focus on is the benefits that will be realized by using this new system and how those benefits will affect the organization and the end users. End users often feel forgotten when a new system arrives, so letting people know that they can do the work they normally do with less effort or less time might do wonders for system adoption.
Make The Path of Least Resistance
There are a number of ways you can make using the new system the path of least resistance. Here are just a few:
Templates
Creating system templates in advance can make life simpler for people. In project scheduling, a library (even a small one) of system templates for familiar projects makes the life of a project manager so much easier. No need to raise your voice, the templates will naturally be adopted. At the same time, your new templates will bring a bonus of process changes such as coding standards, naming conventions, report standards and more. For our timesheet clients, templates can include pre-loaded timesheets with assignments already there and banked holidays already in the timesheet. Templates are awesome.
Familiar Data
When the data looks familiar in a timesheet system like our TimeControl, most of the challenge in system adoption evaporates. There is the data the end-user expected, just where it’s supposed to be. We often work with new clients to ensure the same data structure can be adopted in TimeControl.
Familiar terms and lexicons
While we’re talking about familiarity, how about the language that’s used in the system. I’m not just talking about multi-lingual support though we believe in that too. We’ve taken pains in our own design to ensure every label and message can be customized and that those language changes survive each upgrade. So, if everyone in that organization calls a “Project” an “Account” then go ahead and change it. If everyone calls a “Charge” a “Task” then go with the familiar term. It will reduce stress and increase end-user happiness.
Expected Workflow
There are many reasons why a new system might encourage an overhaul of the workflow that has become familiar. Our recommendations are almost always to keep with a familiar movement of data through the system until the new system has become familiar for everyone then start adjusting the workflow gradually.
New Rules
When we deploy our timesheet system, we often have a moment as we’re describing TimeControl’s automated validation rules where someone in the organization lights up with excitement. They envisage all the rules that they now have to check for manually now and how they will now be able to push those rules out to every user. We explain that system adoption is best handled by having a small number of such rules and then, once the system is generally accepted, introducing new constraints one or a small number at a time. This concept goes double for when you are deploying to people who are remotely connected.
Imagine this scenario: The new timesheet arrives, “Fine,” says the user and fires up his first timesheet in the new system. As he hits the submit button, the timesheet says “Sorry, but you have put sick leave on a weekend.” “Hmmm, good catch,” the user thinks and fixes the error. He hits submit again. “Sorry, but you have used the wrong rate code on line 4.” “What?” thinks the user and goes to make the fix though he’s not exactly sure what the problem is. Fine. Submit again. “Sorry, but you have put hours on a task that you were not originally assigned to.”
Now the user doesn’t say fine. He closes the application and informs his team lead that perhaps a rocket scientist could finish his timesheets.
True story: I once explained that story in a room at Canada’s Space Agency where they informed me that they had plenty of rocket scientists handy so this might not be a problem for them.
Training
Training once meant getting in front of people in the same room and explaining things. There is much less tolerance for that these days. Make training a Do It Yourself kind of thing. One way to do this is through mini video lessons. There are many tools for this now and it doesn’t require a lot of experience. Just make bite sized videos of basic functions. If you keep the videos to 3-5 minutes, they will not be too onerous to watch when someone needs to overcome a challenge in the new system.
Make resources easily findable
You may have many different types of resources to help new users of different kinds to adopt the new system. That might include flow diagrams for people to understand what happens to their data once they enter it and process explanations that show how the data is consumed. If you have automated validation rules, it’s a good idea to make a list so people know how to make an acceptable timesheet. There might be online videos or online references. Making all these resources available to your users is more important if you are working remotely. For people who are disconnected physically from the office, it’s just not as easy to walk down the corridor and ask a colleague or a resource person.
In TimeControl we’ve made it possible to list references such as these right in the system dashboard or, use the Menu Editor to make links to those resources right in the help menu.
Deploy in Phases, not a Big Bang
I’ve talked about this so many times but rather than a one-moment big-bang, roll out an enterprise system in phases. They can be big phases but make sure the first few are well taken care of. If you choose the most likely to succeed groups as your first to deploy teams, then once you get to the most resistant groups later in the deployment you may find that resistance has dissipated. When there is consensus throughout an organization to move in a particular direction, it’s difficult to keep being the standard-bearer for the cause of “don’t change”. If you’d like to read more on my thoughts of phased approach vs. big bang, take a peek at this article here in the blog.
We’ve only touched the surface of course, but if you start with the understanding that adoption of a new system isn’t a given. People who use the system are the ones who have to accept using it in the end and if those very people are working remotely they will need a little more attention than you’re used to.
