Increasing End User Engagement

My first real project where increasing end user engagement was a top priority (if not THE top priority) was back in the mid-1990’s while working for Pacific Telesis Shared Services, which, if the name wasn’t too obvious, was an IT shared services organization that split off of the Pacific Bell mother ship (in San Ramon, CA) to provide tools, services, and data center management for the family of Pacific Telesis companies. As a project manager assigned to identify, deploy, and support many of the front-end tools accessing the massive amounts of data we managed through several data center locations, change management was a huge priority, which meant managing a lot of service requests from an often demanding set of internal customers, many of whom were data analysts using our platforms and tools to provide reports and data for an even larger set of internal users. One of the projects to which I was assigned was to build out a change management methodology and easy-to-follow intranet site for this methodology, automating as much as could be automated.

Of course, in the mid-nineties we did not have the tools and capabilities we do now. I had to learn HTML and some VB, and built many of my interaction visuals using Corel. When the site went live, the users had a visual workflow of the change management process, and clicking on any part of the flow took them to related documentation and some simple forms. Maintaining the site, unfortunately, was a very manual process – but feedback was very positive. It’s very rewarding to see something you’ve built actually get used.

But what made all of my effort come together was less about my technical skills, and more about the steps to get to that end-point. The project began with a vision from my Director and a charge to enlist the help of key stakeholders and end users at every step. I held a formal project launch, provided weekly status reports, conducted numerous requirements group and one-on-one sessions, and rolled out a pilot to a sub-set of users for feedback before refining the final site and going live. And once live, I also provided training sessions and, once again, one-on-one sessions with end users and my management team, wrapping up the project with a sign-off from my Director that what we delivered had met all of her goals and expectations.

Thinking about this Pacific Telesis experience, here are some considerations for increasing end user engagement within the modern workplace:

1. Collaboration must have a purpose. The intent of the site we built was not just to share process documents, but to ensure that people were following the defined methodology. We tried to make it as intuitive as possible (i.e. idiot-proof) so that people knew exactly where to go to get the right documents and contact for any step within our methodology. While we did provide links to other relevant sites and content, we focused our design and efforts around our primary business function, avoiding the trap of scope creep.
2. Include an intuitive and inspiring user interface. By making the methodology visual, using a single (albeit moderately complex) workflow at the top of site, end users always understood exactly where they were as they navigated the site. I don’t know how “inspiring” the site was, since we were using Corel to design the various elements, but feedback was that it was functional and intuitive. But the proof was in the data: people actually used it, which is the whole point.
3. Involve your end users. We involved end users, as well as IT and business managers, at each phase of the project. Additionally, we piloted the site and made sure we received sufficient feedback before finalizing our design and taking the site live. I remember driving from our offices in Hacienda Park in downtown Pleasanton, California over to the San Ramon headquarters of Pacific Bell so that I could drop by and meet with some of our key end users. It’s important to have both formal and informal sessions to get the best feedback.
4. Have clearly defined roles and responsibilities. If you’re a formally trained and certified PM, this is pretty much Project Management 101. But having clearly defined roles and responsibilities, and then setting expectations and accountability for each role is key to long-term success. When I received push back from my own management team, who were just too busy to give feedback, I asserted myself and reminded them of their accountability. On an ongoing basis, its also critical to understand who is managing your platform. You may not have formal service-level agreements (SLAs) in place, but it makes sense. When people understand what is expected from them, they are more likely to do what they are supposed to do.
5. Hold dedicated events. We had a formal kickoff, formal and informal requirements sessions, design reviews, pilot activities, user acceptance testing (UAT), training sessions, a launch event, and a post-mortem. This degree of meetings may seem like overkill – do what makes sense for the size and culture of your organization – but goes a long way toward transparency and communication. That’s what its really all about: communicating what you’re trying to accomplish, communicating as you are building and deploying, and communicating once you have delivered. Err on the side of over-communication.

The end result of all of this, I promise you, will be a higher level of adoption and engagement across the board. When people are involved in the process, they are more likely to accept the end result. If you’re looking for more guidance on how to incorporate these steps into your own environment, my advice is to run a pilot.

If you’re not yet convinced that focusing on end user engagement matters, take a look at what Microsoft is up to lately. A sizeable majority of the innovation coming from the Microsoft 365 team has to do with increasing end user and team productivity, which is part of their larger adoption and engagement strategy.

We’ve all participated in the creation of something – a website, a tool, a process – that may have been the “right” think for our team or company, but that lacked support from leadership and/or end users. And so it failed. I can’t tell you how many times I’ve heard from customers who went about deploying SharePoint the wrong way, and even though they eventually “got it” and delivered what end users wanted, the damage had already been done, and their end users refused to support anything with the ’SharePoint’ label attached. It can take considerably more time and cost to win your end users back over than it would to take the necessary planning steps up front, and get end users involved. (for more on this concept, check out my old post on Breaking the Suck Threshold)

Just because your efforts may have gotten off on the wrong foot does not mean that it’s too late to course-correct. Evaluate your existing strategy (or lack thereof) and walk through the steps above.