Authors note: The following article is based on my experience trying to persuade environmental scientists, field technicians, and managers to adopt software technologies in the environmental consulting industry, an industry generally averse to software adoption due to their time & materials billing approach (i.e., less efficient = more billable hours). Other industries may differ from the experience described below.
The top-down approach many firms use for implementing mobile software technologies
Many firms use a top-down approach that looks something like this:
- Senior leadership becomes enamored with the idea of adopting a new mobile technology, not only to improve internal efficiencies, but also for other reasons, like for example the ability to publicly emphasize how “innovative” and “forward-thinking” their firm is, even when they are not actually “there” yet. After all, no firm out there wants to publicly sell the idea that they are sticking with tried and true older technologies. You just don’t see that sort of advertising or press from firms. They all mention how innovative they are. Just visit any firm’s website for proof.
- Once senior leadership selects a particular software tool, they bring in the IT team and/or a senior manager to lead the charge with implementation. This person or team will typically start by identifying low-hanging fruit to conduct a pilot test on. That is, a small department or work group that they feel could benefit from the technology being adopted at the firm.
- Many meetings later, a pilot test is established, wherein the field staff within the designated department or work group is required to use the technology, sometimes in parallel with their existing workflow.
- Several months later, the new software technology is mostly abandoned, as most of the field staff shuns the technology and continues doing their work as they always have.
Where the top-down approach breaks down
Probably the most significant disconnect with the approach described above is the lack of involvement of the people that will actually be using the technology in designing the system that will be imposed on them.
Forcing staff to use a software product leads to very poor adoption. You improve it by allowing them to help design the system
How to make fans out of detractors…
Start by involving users in the design process from the outset. And you don’t need to involve all of the end users of the system. Design-by-committee never works. You only need to convince a single individual to help with the software customization and implementation.
Just one person.
But the right one.
Lets call this person Joe.
Joe is a seasoned field tech that is willing to help design something that he will be using himself. Willing to at least have an open mind about the idea. He also has a good level of influence and respect among his peers that work alongside him. And Joe’s boss made it known to Joe that his productivity during the design phase will not be judged whatsoever. That his “non-billable” time assisting with the development of the new system is ok and in fact encouraged because it will have a large impact across the entire organization. A small one-time bonus to Joe for going beyond the call of duty and helping with this important task also helps persuade what used to be a negative mindset about the whole thing.
Deploy the imperfect system, get feedback from Joe, tweak, repeat
Best way to get something implemented is to just get it out there and test it.
It doesn’t have to be perfect.
It only has to be good enough. The feedback loop with Joe will take care of the rest, as long as you continue to iterate and change it quickly based on Joe’s feedback. The faster you can update the design and re-deploy, the faster this process will go.
And as you improve the system, Joe’s optimism will increase. At some point during the process, Joe will start to use the system almost exclusively, instead of in parallel with his tried-and-true process. This is when you have made Joe a fan. Your internal influencer.
A respected, internal fan attracts more users within the organization…
Once Joe starts using the system which is now based on his feedback, he will start telling others around him about it. And since it’s coming from Joe, not upper management, it will be more likely to be adopted and tested by the other folks within the organization. No need to coax others to giving the new system a try. They will do it because Joe uses it.
That’s all there is to it. So to summarize….
- Find your Joe
- Get Joe to help design and test the system
- Continually improve the system based on Joe’s feedback
A true story
“You’ll never get Gary to use XForms.”
That’s what I heard from a couple of folks at Mid-Atlantic (MAA) when I started developing some field forms at the company around the fall of 2020, when COVID was a really big deal around these parts.
With 27 years of field work under his belt, Gary is MAA’s most seasoned and efficient field tech. By far. He can tell you pretty much anything about any of the wells he’s sampled over the last quarter century. I don’t know how he remembers all of that, but he does. Gary’s field notes methodology was to take down meticulous notes in the field, fill out paper forms, and then re-write the field notes into more legible versions when back in the office.
When I started working with Gary, I asked him lots of questions about his field work…what type of info he collects for each type of form or field work type, what’s most important, what’s not so important, what could be automated or pre-populated to save field time, what forms we should skip and leave to paper, etc.
On the first pass, there were issues….XForms had problems with photo capture resolutions being too large…the save button was a green checkmark at the top right of the screen and was too far away from a user’s thumb to fill out forms one-handed on an iPhone…some fields were missing, some forms needed redesigning/simplification compared to the paper forms, the PDF formats sucked, some listboxes needed more selections, etc.
On the second pass, things improved a bit, but other issues were observed…some data was lost due to app crashes, offline mode wasn’t working right and some offline forms didn’t sync, time values on the PDFs didn’t match the time values on the input forms, etc.
On the third pass, things improved incrementally…on the fourth pass…you get the picture. The point is, Gary didn’t abandon ship and neither did I. We worked through the issues. Every now and then, in the afternoon after his long field day, Gary would pop into my office and provide feedback on his experience that day or week using XForms. We’d discuss the issues, and I’d get right to work tweaking the forms, adding values to listboxes, discussing user interface changes, etc.
Over several months, the forms and the entire system improved, to the point that Gary became a fan of XForms. It was not an immediate thing…more of a gradual thing, from about November 2020 to about May 2021. By then, the system (and the platform) were robust enough and had been optimized to the point where others within MAA started using the system as well.
Want to check out XForms?
While the system has some self-service components (so that you can build form templates yourself), there are also humans behind the scenes that can help you design, develop, and implement the system within your organization. At a pace that suits you. Just like what was done at MAA.
Give it a look. Click/tap the button below.