Working with Subject Matter Experts (SME's)

Basically, what it comes down to is don't be this guy (XKCD link).

A few years ago my regional health network rolled out an electronic patient record system, and I spent some time as a trainer working with doctors and nurses in various one-on-one, one-on-two, and classroom-based sessions in a variety of hospitals and clinics. It was both tremendously interesting and tremendously educational. Some of our people were thrilled that we were finally "entering the 21st century", but others not so much.

There are several reasons we encountered pushback. The first is a general mistrust of people who think they know about the field but don't have the education or experience to back it up.

Medical professionals didn't get where they are easily. They spend a lot of years in school, and then they spend their whole career working hard to be really good at one particular thing. They pay attention to their workflows, constantly improving them, and the results are demonstrable. Their skillset is relatively narrow but it's very deep. At the same time, what they do is important and they know it. Their actions often make the difference between life and death. It's a big responsibility, and obviously they're conservative about making changes.

The second reason is that they've learned from experience that most medical software is crap. Sometimes it's not designed for people in their specific job, sometimes it's not well designed for anyone at all. The interfaces are clunky and the back ends unstable. It's not purchased by the same people who use it. And even in the best case, where the software is easy and stable and fits their needs well, there's still a learning curve which means that at least temporarily they are guaranteed to be less effective than before—with a direct effect on patient care.

So as you suggest, building trust is key. We used a three-pronged approach.

1. First, we got buy-in from internal champions. We started with the leadership of each organization, and then opinion leaders within the organizations whatever their job title. Our users respected these individuals, so that really got us in the door. Also the nice thing about having buy-in from the top is that they have the power to mandate attendance at training sessions. Given their druthers, most of our people would rather have blown off the sessions. This way they may not have been there quite by choice but at least they were there.
2. Second, we made sure to go in humbly. I'm not a medical professional and I know it, and I know how foolish it is to claim to know anything about their processes better than they do. When our people saw that we were respecting their expertise, they relaxed. I think this was the main thing really.
3. Third, we put effort into understanding the users. We learned the basics of their workflows and their vocabulary, and paid attention to the differences between user groups and between individual users. Being present only at the implementation stage of the software meant we didn't have a whole lot of control over the interaction, but we were able to identify important bug fixes and customizations that the programming team was in some cases able to implement. You'll be able to do a lot better in this area.

Also, at the end of rollout at each organization, we had cake. Everyone likes cake.

Good luck!