Tech Paper: End-User Communications

Overview

‘End users don’t like change’ is the feedback we often get here at Citrix. When undergoing migrations, IT teams go to great lengths to minimize any changes to the end-user experience. Change to the end-user experience can often lead to increased help desk tickets and reduced satisfaction.

Citrix has several tools and features to help reduce changes to end users. These tools include vanity Workspace URLs to maintain your access URL and site aggregation to consolidate and maintain icons. However, even with all these capabilities, sometimes change is necessary due to software updates or other organizational goals. So, how do we implement change with the least amount of impact on users?

In general, there are two key groups you need to communicate your changes to to help ensure a smooth transition: end users and the help desk. Let’s discuss further about what needs to be communicated to those groups.

End-User Communications

End-user communications need to be clear, consistent, and well-timed. You don’t want to overwhelm your users with communication, but you must ensure they have the information they need before any changes begin. This section will discuss the end-user communications that must be sent out before, during, and after your changes.

Test

Testing

Any change implemented in an environment needs thorough testing. It is important to validate the changes against all impacted use cases when testing. You need to work with application owners or business unit (BU) leaders to identify all the use cases the environment supports. Once the use cases have been defined, all impacted end users need to be identified along with relevant distribution lists for future communications.

Your IT administration team's involvement in testing the environment, commonly known as 'dogfooding' or eating your own dog food, is important. This process ensures that administrators understand the end-user experience and can catch things that a regular end user might overlook. Dogfooding acts as a form of quality control and ensures that the IT team understands the end-user experience.

Once the use cases have been identified, power users need to be identified for each use case. Power users are defined by their ability to provide constructive feedback and willingness to try out new systems. Power users being chosen based on their responsiveness and ability to effectively communicate about any issues they find ("App X is lagging when I connect to the database clicking this button" rather than '"Citrix is slow") is important. It is helpful to provide them with a list of things you need tested. Some examples include applications, peripherals (printers, scanners, and so on) or video call experience (using Microsoft Teams, Zoom, and so on). You must validate any capabilities that are part of a user's daily or weekly tasks.

As a part of your testing, document how the process is supposed to work. This information is documented as a part of a walkthrough guide and video. This documentation is discussed in a later section.

Change Advisory Board (CAB)

Implementing changes often requires the approval of the Change Advisory Board (CAB). This board reviews, evaluates, and ultimately approves changes to the environment. The CAB is critical for ensuring business continuity while implementing changes.

All plans for the Citrix change need to be submitted to the CAB before the change. The lead time for submitting the request varies depending on organizational rules. When submitting a change request, the plans for implementing the change and the rollback plan needs to be included to get CAB approval. Ideally the change has already been rolled out in a dedicated test environment first. The proposed production change is a straightforward implementation of what was already done. You need to define any necessary maintenance windows or impacts to end users. This approval process starts during the testing phase before rollout.

Inform

There are two major pieces of information that end users need to know: that change is coming and when that change is coming.

Change Announcement

A change announcement needs to be made to affected users. During the test phase, affected users were identified. For communications, email distribution lists were also identified or created for all the affected user groups. If you have users who don’t regularly use email or use kiosk-based machines (such as workstations on wheels), it is recommended to print communications for those users. Communications can also be distributed using banners via NetScaler, StoreFront, or Workspace to notify users of upcoming changes.

When drafting communications, use your company's standard communications formatting. If your company does not currently have standard formatting, you can reference our End User Adoption site for editable templates. This communication includes the time frame of the change, the change, its expected impact, and who to contact if there are issues.

Migration Communication

Users must be informed when they can expect to be affected by the changes. Users need to be informed before the migration following internal standards for change communication. If you don't have an existing standard, it's better to over communicate than under-communicate. Communications can be sent out 1 month, 2 weeks, 1 week, or 2 days before the change. The communication can be phased or general, depending on your migration strategy. For a phased migration strategy, your communication is phased as well and sent out to the appropriate users during their phase of the migration. Users need to be informed about several key pieces of information:

• Dates: The dates/times they are migrated to the new system.

• Changes: The exact changes and how they impact the end user. Documentation such as walkthrough guides and FAQ documents to be provided.

• Help Desk: Who to contact in the event of issues that aren’t covered in the walkthrough or FAQ document.

Migration

It’s now time to migrate to the new system. If possible, it is recommended to do a phased migration to help minimize help desk tickets or impacted users if a rollback is necessary. When moving users from one environment to another, removing end-user access from the old environment is often necessary to force them to switch over. For example, if you’re moving to a new Citrix Virtual Apps and Desktops site with a new access URL, you want to disable the applications or Delivery Groups in the old site to force the users to use the new environment to access their resources.

During the migration, you can use tools such as Citrix Monitor or Director to view the usage of the new environment and ensure that end users are adopting the changes. It is also important to monitor for any alerts or any sort of issues. The Citrix administration team communicating with the Help Desk to keep track of the tickets coming in and if there are any unexpected issues is essential. If enough issues are occurring, a rollback may be necessary. As you roll back per your CAB plan, you must send out end-user communications to inform them of the rollback. It is recommended to have these communications pre-drafted so they can be sent out as soon as possible in the event of an issue.

Documentation

Walkthrough

Walkthrough documentation covers the new end-user experience after the change. A walkthrough is a step-by-step guide with screenshots that show every step and click-through of the end user experience when going through their workflow. Walkthroughs can give the end user confidence in their new experience, so they understand which changes are intentional and expected. A walkthrough video can also be helpful to show the experience as well.

FAQ documentation

End users are going to have questions about the change. If you are removing or adding a capability, you need to explain what functionality changes are happening and why users might need to use a different workflow. During the testing phase, document common questions asked by the test users in the FAQ documentation. This FAQ is a living document, and if you notice any other common questions during your migration, update the document to include those questions.

Rollback communication

During change windows, things don’t always go as planned. If unexpected issues occur, you need to send out communications to the end user that you need to roll back. This communication includes instructions on what to do to access the new environment and potentially a time frame in which the rollback takes place, as some rollback changes will not be instantaneous. It is recommended to pre-draft these communications before the change. That way in the event of a rollback the communications can be sent out immediately.

Help Desk Communications

When going through a change, keep the help desk team informed of the project plan and the timelines. The help desk is your front-line support to help users through the change. Having a well-informed help desk improves end-user experience and migration changes.

Test

Although the help desk is usually not directly involved during testing, it's important for help desk leadership to be aware of the testing timelines and the planned changes. During the testing phase, the test users contact the Citrix team for assistance, not the help desk, as any identified issues will likely require Citrix administrator expertise.

Inform

Informing the help desk team about the migration plan and the specific timing and number of users being migrated is important. This information helps them prepare and expect increased volume around those timelines. Before the migration, meet with help desk leaders to walk them through the new user experience so they can understand the end user's perspective. Include any expected issues or concerns of end users in this meeting. Create a knowledge base or support articles for any issues identified during the testing phase. These articles enable easy troubleshooting during the migration.

Migrate

As mentioned previously, the help desk teams are aware of when the major migration dates. Knowing the dates enables the team to staff appropriately for an increase in help desk tickets. During the migration, the help desk is the first line of support for end users. The help desk can handle low-level issues covered by the FAQs and knowledge base articles.

The Citrix team needs to keep in regular contact with the help desk, either through status emails or meetings, to track the type of cases the help desk is handling. This feedback helps guide any updates to the FAQ document or further troubleshooting from the Citrix administrators. In the event of a rollback, include the help desk in those communications for awareness.

Documentation

Provide the help desk access to the documentation the end users are referencing, such as the walkthrough guide and FAQ document. The help desk also needs access to support documentation that covers common issues and how to resolve them.

Knowledge Base Articles

Create knowledge base articles (or specific documentation your support staff use) and hand them off to the support teams. Include the following in the documentation:

• Symptoms of error
• Problem Solution
• Problem Cause

Ensure all members of the help desk staff have easy access to this documentation, and update the documentation regularly, either by the help desk or Citrix teams to ensure all content is relevant and accurate.

If any common issues can be resolved by actions the end user can take (for example clearing internet caches), make those Knowledge Base articles accessible by the end user. This will help deflect future support tickets.

Summary

Change isn’t always easy but it’s possible. By preparing all your teams and end users, you can ensure a smooth transition with as little disruption as possible. With any change, preparation and communication are the keys to success!