1) Users are stakeholders
Treat your users as stakeholders from the beginning of the process. Make sure they know what's coming and are involved in the planning and requirements process. This can be critical to understanding all your use cases. I’ve witnessed implementations whose requirements were narrowly defined by one or two people that have a lot of last minute changes at the least desirable time: Go Live. This increases the complexity of your roll out, and really magnifies risk and cost.
Listening to user needs not only helps you to understand all your use cases, but it makes them feel that they're a part of the project. When you have users that become resistant and uncooperative to a new software initiative, perhaps they felt excluded or outright ignored during the acquisition and planning process. Involvement with the project can transform a user from critic to advocate, because they now feel an ownership for what’s happening, and this can generate the excitement needed for them to buy-in and become a vocal fan. The hallway or water cooler conversation now changes from the mode of critic (“I hate what they did with the new system. I don’t know who designed the layout!”) to having your former critics as your defenders (“Let me show you why we designed it this way”).
Many projects often struggle to find a single champion or super-user. This approach often simplifies finding those people and more people contributing to the end result is going to lead to better results. Users who have the passion behind your direction will emerge on their own through the project, and they’ll be much more driven than if you had picked a random staff member and assigned the responsibility to them.
2) You’re only as strong as your weakest link
When you roll out software, you’ll have voices that boom louder than others with the potential behind the new software, what it can do for you, and how you can maximize it’s features. There are other voices too... some substantially more silent, that are very necessary voices to hear. I’m talking about users that may struggle with new technology.
There can be a natural conflict arising with your organization between those that drive the pace of technology the quickest, and those that are always struggling to catch up. The perfect storm for this conflict occurs when new systems are deployed, and this can lead to some very frustrating interactions, and even bad feelings that can cause deepening rifts between your staff.
A doctor I once worked with shared a story and an idea that I still find very valuable. He was a volunteer with the Boy Scouts. When they would go out on hikes, he would never be at the front of the pack pushing the pace. He would be at the back, although athletically, he didn’t need to be. There would always be someone struggling at the back, and he was always looking out for them, and how to lighten their load, and help them catch up.
He applied this outlook to his professional life, and he actively advocated for those he felt were struggling, yet weren’t speaking up for various reasons. I came to respect him and what he was doing. I’ve since seen this outlook applied in other places, and it really makes a difference when the team lines up behind the member most likely to struggle with a change, and insist that they will not leave any member of their team behind.
The results are very visible. The team members that might have otherwise struggled were happy. They were proudly self-sufficient, and they felt comfortable because of that support. It turbo-boosted the morale and mood of the group when it came to the software and it boosted team unity and cooperation. The key thing here is this wasn’t an accident. It was a deliberate and frank discussion among the team, and an honest assessment from the users that thought they would need a bit extra. It wasn’t about people’s pride or blame, but about the team knowing themselves both as individuals and as a team, and executing like a team.
3) Execute as a team
This leads to my final point. Learning is very individual. This doesn’t have to be viewed as a liability, but can be designed as a benefit. There are many opportunities for the group to benefit from individual differences.
One of the successful habits I’ve seen among groups that were able to deploy and utilize software successfully is that the deployment didn’t end at Go Live. There was a concerted effort to continue to learn and develop. There was time set aside in their weekly meetings to discuss everyone’s experience using the software, so that people can share what they’ve learned that’s helped to make them efficient, and the group can benefit from the tips and tricks that each person naturally accumulates in the learning process.
At Voicebrook we do this as a regular company-wide weekly effort and we call these knowledge sharing sessions. The ability to learn best practices and share from other team member experiences accelerates the learning process for everyone.
A big part of this, as it relates to VoiceOver, is content templates for building out reports. We’ve found that sites that share and collaborate with their templates are more successful. They are always looking for ways to share and help the group move forward. These sites also get the benefit of consistency and standardization. Especially among pathologists, this can be a struggle. Many sites have told me outright that they don’t believe they’ll get consensus on formatting among their pathologists, and just want to let each user do their own thing. This kind of structured, planned collaboration on templates drives the discussion, the give and take, and ultimately, decisions to standardize when each person spends some time understanding each other’s perspectives, and this helps influence everyone to come closer together towards a common standard.
If you made it this far than I am sure you identified the common theme that drives technology adoption success. It’s working as a team. Our most successful software deployments have never been driven by one or two superstars. Our most successful sites and biggest advocates have a team focus where everyone is participating and working towards common goals. Hopefully this blog provided some ways for you to help focus your team on these important principals and you can apply some of these principals to make your next technology deployment a success.
To learn more about best practices when kicking off an implementation, please read Michael Gonsalves blog Post, "3 Ways to Help Prepare for Your VoiceOver Implementation".