We humans are creatures of habit. Good luck getting us to change, especially if we’ve been doing something for any stretch of time. We’ve all seen how things all too often go during software rollouts in our organizations. Cries of, “why can’t we just keep the old system?!” echo through the hallways. And in construction, this sentiment is even more prevalent. “I’ve been using paper and pencil checklists my entire career and now you want me to use an iSomething?!” Meanwhile, you’ve spent the last six months researching software solutions that will not only provide more visibility into your project work, but will also decrease your timelines and costs. But if no one uses the system, it’s not much good, now is it? So how can you get your team to use the new system you just acquired? Here are some proven approaches:
- Communicate, Communicate, Communicate: Software adoption is a process that needs to be planned prior to a system going live. Hold meetings in advance of the launch. Let everyone know it’s coming BEFORE you want them to use it. Then rinse and repeat. Continue to communicate the “what,” “when,” “how” and “why” before and after launch. The mere fact that you are continuing to talk about it will send the message: “This is important.”
- Don’t Forget the “Why”: “Why?” is a key question to address in any change management effort. It’s not enough, nor is it fair, to tell your team to do something without also providing a rationale. And that rationale should be multi-layered and personal. Explain why the new system will benefit your organization, project and individuals. “Not only will System X reduce our overall project costs, but it will give our Project Managers a real-time view of what is going on and will give our subcontractors an easy way to know what is assigned to them for completion.” Be specific.
- Walk-the-Walk: If you are the person responsible for the purchase of a new system or have simply been charged with getting it in place, make yourself a believer before you try to convert others. Know how it works, take the training, and be able to do a demo. If you really understand the solution, you will be much more comfortable singing its praises.
- Put Champions in Place: Find people on your project or in your organization who are willing champions of the solution – preferably at different levels and in different roles. These are your ringers. You may choose to give these folks advanced training so they can spread knowledge faster. But more than anything, you want them to own the success of the solution.
- Train Your Team: This sounds obvious; of course you’re going to train your team. However, we often see training that is too narrowly focused or too technical – or not technical enough. The key is, know your audience and segregate them appropriately. Do your trade contractors need the same training as your architects? Probably not. Tailor the training to specific roles and how they will ultimately use the system in their day-to-day jobs.
- Make it Legal: If your solution is to be used by external organizations and people, think about making their use of the new system part of your contract with them. I always encourage people to run meetings from the software. If your project status meeting starts with a review of overdue issues by firm, you can bet that nobody is going to want to be on that list…
Not all of these ideas may apply to your unique situation. But if you enter the adoption process with these concepts in mind, you will be well on your way to creating a new habit for your company.