Don’t Forget Your End Users in Your Collaboration Planning

As with many of you out there, Microsoft Teams has become my primary collaboration and communication platform. I manage my client activities and engage with community groups through Teams. As I was reviewing discussions in one of these community spaces, I read a few comments that reminded me that not everyone spends as much time as us “experts” in keeping up on what is happening with the platforms we use, and how this lack of visibility and participation in the collaboration planning process can severely impact the quality of your deployment.

I had this in mind as I sat down this past weekend to review my 2020 content plans and started constructing several abstracts for sessions that I plan to create this winter and into the spring. While I’m still reflecting on the specific topics and technologies that I’ll be covering in sessions in H1 of this year, I do feel like I have a backlog of content ideas for the blog. I’ve decided to go back to my roots and focus on the content areas which have made up a huge portion of my career: project and change management, corporate and systems governance, adoption and engagement, and the basics of team collaboration and communication.

As I was going through old content this week for my end of year post, one of the recurring themes since this blog was started in 2004 has been best practices for systems planning. Much of my writing stems from personal experiences back in my telecom and startup days, which is where I moved from project and portfolio management solutions into the collaboration and knowledge management space. One piece of imagery I’ve used frequently when talking about collaboration planning is the iceberg: what you see on the surface is the technical aspect of the effort — the moving of data and solutions between hardware (on-prem or cloud). But under the surface of that data movement is where the real work begins. There is a massive planning effort to successfully launch and deploy a solution — regardless of the solution — that truly determines whether the resulting environment will, ultimately, be successful.

Since my first hands-on experience with SharePoint migrations 15 years ago, helping organizations move from SPS 2003 to MOSS 2007, one of the best practices I have always employed is to reach out to end users early to involve them in the planning process. Because the platform is used (and depended upon) by end users, it is important to keep them in the loop on what you’re planning, get their help on prioritizing and classifying content, and inform them of changes as the plan is being executed. Including them in the planning process is a key to long-term adoption, because the more you involve people in the process — the more likely they will support the outcome. That’s a lesson I’ve learned (sometimes painfully) through trial and error.

Whether deploying a new platform, migrating between platforms, or upgrading to the latest and greatest version, content will be added and reorganized, and new features will be introduced. Don’t assume that just because you’re moving from SharePoint 2010 to SharePoint Online and/or rolling out Microsoft Teams that everyone knows how to use these new features. Many of us learn by doing, and can become quite proficient without any formal training, but some degree of formal training can expedite the learning curve from end user to power user, and help your business get the most out of its investment.

You must decide where and when to involve your end users before you begin. This is the most fluid of your strategic considerations as you balance the risks, requirements, and realities of your new platform. How you include your end users really just depends on:

• who your users are (are they power users, or do they only consume content from pre-defined sites?),
• what the current environment looks like (not just look and feel, but how is it being used? Is it out-of-the-box or do you use it for more complex business processes?), and
• the overall goals of your platform (Are you simply moving the content as-is into a new environment, or are you orchestrating a complete transformation of content, design, and functionality?).

Another important consideration when planning for end user involvement is to understand the culture of your organization. For enterprise-wide projects, how do you normally involve end users? Do they help drive the process, are they brought in as part of a clearly defined process or IT methodology, or is it completely ad hoc based on role or individual?

Some of the areas where end users should be involved might include the creation of use cases, creation of your as-is or current state documentation, identification of outcomes for future-state environment, and the identification, reorganization, and classification content. Your users know their content and the business processes that drive them – so put them in charge of any activities around content migrations, data classification and taxonomy development, and signoff of the overall project plan.

No matter how you involve your end users, be sure to include them in your plan, reach out regularly for feedback, and be flexible in how you shape the design of your future environment.