Plan a pilot
When planning a pilot, ample time should be allowed to perform sufficient testing prior to deployment. Once testing is complete and all known issues have been resolved, the deployment itself should be rolled out in phases. There is always the possibility of external factors that weren't identified in the lab that can suddenly appear and impact the deployment. Even if a deployment doesn't result in any technical complications, IT staff should be prepared to support the impact of the deployment on the end-users. Failure to provide sufficient resources to train users and address questions or concerns can have just as negative an impact as a software or hardware issue.
Phased deployment
Phased deployment using deployment rings is the concept of starting with small groups then broadened deployment scale in a measured way over time. Normally by the time a communication and training plan is drafted, these rings and their members should be formed. This way, you can reduce potential risk and validate your approach as you continually open the deployment valve, or pause activities if needed, for example, when you see more helpdesk calls come in than expected.
Deployment rings are best created in cooperation with business units and their managers. You'll want an understanding of critical dates and times to avoid when deploying or making changes. Without careful planning and buy-in from stakeholders, it will be difficult to get users on-board and comfortable with any changes coming their way.
Phase 1: The IT team and early adopter insiders
It's usually best to begin your deployment with the IT team and enthusiastic early adopters, who volunteer for early access. With these "insiders" you can test your communications, the impacts of change and the effectiveness of your communications and training. During this phase, IT runs small pilots, learns troubleshooting and automation techniques to help during broader deployment phases.
It's important to have engaged members in the initial pilot phase, to make sure they are documenting their observations and feeding back to the process. Also, it's good to have champions outside the IT team that help extend organic, word-of-mouth communication of new capabilities, and they'll often be first line of support when users in later phases need help.
Phase 2: Pilot
Once you feel good about the first phase, you can target a larger set of users for your second, pilot phase. This should comprise a representative mix of user roles, device types, apps, Office add-ins, etc. Pilot devices should also be low risk users or devices to further minimize impact to business during the pilot. The data returning from these groups will be used via Analytics to target the initial waves for phase 3, the broader deployment.
Remember, all PCs in this phase and future phases should be logging up to the Analytics service, so you can collect diagnostic data about device and app health as well as bandwidth savings. Desktop Analytics can help determine candidates for pilot groups and identify potential issues that might be difficult for users to identify or neglect to report.
For this phase it is especially important to communicate changes and help users take advantage of new capabilities. Users can often de-prioritize or ignore email or other communications coming from IT – so it helps to meet with management to get their help in communicating change and drive adoption of new tools and technology.
You'll also need their input on timeframes to avoid, so you can minimize user disruption. For example, the finance team may be particularly sensitive at the end of fiscal quarters or product development teams during a product launch.
In parallel to planning for devices, users, departments and timing, you can start to build your communication and training plans, as well as begin compiling content or engaging outside resources to help train users.
Phase 3 and beyond: Broad production deployment
By the time you reach broad deployment phases, you'll have refined your processes, communication, training and self-service tools. Now you can use the diagnostic data collected to target more and more PCs.
Deploy at a rate that is manageable to your IT department, help desk, users and network capacity. You can always go back to Step 2 in the deployment process wheel to optimize your network even further. Also be mindful of your network capacity and use optimization tools such as peer to peer cache, LEDBAT and other techniques to facilitate faster transfer of deployment-related data.
In addition to the diagnostic data that you monitor via the analytics tools, you can also monitor Microsoft 365 service usage in a granular way with detailed usage reports in by workload in the admin center and using the admin dashboards via Power BI. These are great tools to help set and track goals as you roll-out new tools for working together – like Microsoft Teams – or new ways to share files – like OneDrive.
New technology acceptance and adoption will go on long after every PC in your organization has Windows 10 or Windows 11 and Microsoft 365 Apps installed. And users won't necessarily change how they work – without taking the time to inform and train them of new capabilities. Finally, with the new servicing models providing new capabilities on an ongoing semi-annual schedule for Windows and optionally a monthly schedule for Office, communication will be continual.