During Pavia’s August 2nd e–Construction enablement workshop, Beth Chmielowski, VP Customer Experience for Pavia Systems, Inc., shared a proven framework for building successful technology deployment plans. The first three success factors address how to put the right plan into place. In this post, Beth addresses four more human factors that impact the success of technology deployments. Among them, sponsorship is probably the most critical factor to ensuring that your plan actually works.
Watch the entire exchange on YouTube
Pavia Systems User Adoption Checklist
- Ensure strong, active sponsorship at all levels
I’ve helped manage technology implementations across many types of technology and organizations and no matter how different the projects, the one thing they have had in common is that where there was not strong sponsorship, they were very likely to fail.Specifically in the e-Construction space, I’ve learned that there are actually three layers of sponsorship that are important:
- Office Sponsors: The most important one is at the office (or project) level. Someone needs to champion the initiative to get people to actually use the technology.
- District Sponsors: For agencies, because there is often a lot of autonomy at the district or regional level, you have to have sponsorship at each district driving the initiative as well.
- HQ Sponsor: And finally, if you’re doing a statewide deployment, you’ll want to have HQ sponsorship to coordinate the deployment as well as to collate feedback and disseminate best practices and lessons learned. There may also be an HQ-led steering committee that makes decisions about processes or standards that may inform how the technology will be used.
Most importantly, the sponsors need to be actively engaged. These are the people that set the tone of the engagement, that communicate what is happening and why, that offer coaching as people are adjusting, and that hold people accountable when they encounter resistance. Determine what your sponsors will be doing before, during and after the go live date to help ensure success.
- Provide thoughtful and thorough deployment and onboarding This is the set of activities, that is, what you actually do, once you have your goals and plan in place. It primarily consists of communication, training and support:
- Communication should have a regular and planned cadence, starting well before go live, and consisting of significantly more than just one email announcement. Often the people deciding on a technology have been so involved in the selection process, that they forget others may have no idea it is coming. Let them know what to expect, when it will happen and why. Let them know what will be expected of them – what they will start doing – as well as what you expect them to stop doing or do differently.Before go live, schedule a demo, let people ask questions, and share FAQs. During the launch, make sure people know the roll out plan and where to go for help when they need it. After the launch, actively gather feedback and communicate status and results.
- Training should be hand’s on and scenario-based. It should be focused on roles and processes – the things people will actually be doing with the technology to do their jobs – and not on features or functions. It should involve significant practice tied to clearly articulated learning goals (“by the end of this training, participants will be able to ____”). Make sure people demonstrate that they can achieve these goals. For example, if a goal is to create a report in the system, participants should practice creating reports in the system. If you are limited on time, cover less content, but don’t skimp on the practice. If people can’t do something in the controlled environment of a classroom, don’t expect them to be able to do it back on the job.In terms of timing, training should be delivered with as small a gap as possible between training and actual usage. Ideally, offer training within a day or two of deployment. If you can’t train before launch, schedule training as soon after as possible. Expecting people to use something new before they’ve been given access to training is a sure way to breed discontent.Where possible, training should be reinforced by documentation, agile learning content and/or in-app help. That is, give people tools to quickly and easily figure out how to do a specific task in the moment of need. And if you have these tools, build them into the design of the training so people know how to find them and get used to referring to this content on their own.
- Support you should expect to provide proactive support for the first 30 days after go live. This should not be simple, reactive, business as usual tech support. Coordinate active outreach such as a “road show” or “concierge” stations; make it easy for people to ask for and receive help.In addition to technical support, if you are rolling out a new technology in the field, consider providing access to field support to help people use the new technology in their actual workflow. Ideally, this should be provided by someone with domain expertise as well as system expertise.Finally, have immediate supervisors provide coaching to help people become effective with the new tools. This should be supportive, not punitive. There may need to be some leniency as people adjust to the new tool and processes, countered by a clear expectation for when users should be fully on board. For example, provide a “30 day amnesty” but ensure people are working constantly towards the transition.
- Provide peer support: power users in the field
Sponsorship is the top-down way to drive success; peer-support is the grass-roots, bottom-up way. People generally find their peers to be highly credible, definitely more so than a technology vendor, and sometimes more so than management.Identify and recruit people with technology proclivities to be power users to help with the deployment. If possible, involve them in the planning and/or train them early. Have them provide pre-deployment demos. Let them help with field support. Have them gather feedback and escalate issues. When needed, power users can be especially helpful with managing resistance.If you do plan to formalize peer engagement, make it an honor to be a named power user. (It is: you’re tapping their expertise and regard.) More importantly, be sure to make their involvement possible. That is, if you’re going to ask people to offer this level of support to your project, make sure they have the bandwidth to do so. Take something else off their plate so they have the time to dedicate to this.
- Actively gather feedback and be responsive
Communication should be two-way. While communication starts before the deployment, plan for a high level of engagement the first 30 days: determine the cadence for when, how and how often you’ll gather feedback. Actively solicit feedback on any issues, enhancement suggestions, as well as what’s working well. Be responsive; feedback shouldn’t just go into a black hole.Where possible, identify in advance what you may or may not be able to adjust so that you can find and deliver quick wins while working towards high-value (but higher effort) enhancements. Have clearly defined parameters around what you can and can’t change in the technology, and associate timelines with each type of changes to manage expectations.Most importantly, provide regular and balanced status updates, letting people know about any challenges as well as any improvements. People will be more forgiving of hiccups and issues if they see you actively working to improve their experience.
Finally, realize that go live is the real beginning of the deployment, not the end. Helping people to actually use the tool successfully and to realize success with the tool can only happen once they have it. Put some time and thought into how you’ll do that, and you may achieve that soaring productivity after all.