For decades, large IT Transformation projects have been planned using manual spreadsheets or hand-cranked databases. All required steps were neatly visualized in a massive MS Project Gantt Chart — of course, with buffers built in right from the start because we knew there would be delays.
We also knew that the real project devil would be in the asset readiness detail, something that couldn't be managed in a Microsoft project plan. However, we would still spend an exorbitant amount of time updating our scorecards and spreadsheets even though they would inevitably fall apart entirely at some point. It was slow and inefficient.
Now, with the Windows 10 Servicing model and its fast and continuous update cadence, attempting to manage thousands of readiness activities in multiple spreadsheets is useless because managing Windows-as-a-Service is more like juggling hundreds of balls at the same time. Not only do you have to keep the current release balls up in the air, you have to keep your eye on the future balls coming at you just as quickly!
.png?width=1024&name=BasicsofPlanningYourContinuousWindows10ServicingManagement%20(1).png)
[Please note, the article is part of the Definitive Guide to Successful Windows 10 Servicing series.]
From Project To Process: Creating A Scalable & Repeatable Project Framework Is The Foundation For Successful WaaS Management
As you know, once you migrate to Windows 10, you will have access to a new version of Windows every six months. Once on a version, you have between 18-30 months (depending on which release you are on) before it is no longer supported. Considering that the average enterprise took more than 44 weeks (10+ months) to migrate from Windows 7 to Windows 10, it seems inconceivable how a large enterprise could roll out every single release.
However, by redesigning the way you deploy, service, and manage your IT environment, you can create an agile process model that continuously improves and updates your devices.
Over the past two years, we have helped ready millions of devices for the initial Windows 10 migration and prepare for Windows 10 Servicing. Based on our extensive experience, we developed an optimized and streamlined process that can help accelerate your initial IT Transformation project up to 65%. This optimized project framework is the ideal jumping off point for all your Windows 10 Servicing activities that can now be managed in Business-as-Usual.
One way to visualize this agile process is Microsoft's Windows-as-a-Service Servicing Framework:
(Image Credit: Microsoft, 2018)
While Microsoft might be oversimplifying the complexities of the process, we generally agree with the overall decision flow. The biggest difference probably is that Microsoft advocates doing away with project initiation completely, while we (and probably more importantly, Gartner) believe you must have dedicated resources, tooling, and budget to do this successfully.
Just as we have done for your Enterprise Windows 10 Desktop Migration project, I would like to walk you through each of the required steps to plan for an efficient and accelerated Windows 10 Service management framework. The only big difference to the Windows 10 migration framework is that you set up the process once and then cycle through these steps over and over again, so setting up a scalable and repeatable process is essential:
- Pre-Cycle: Project Framework Definition & Set-Up
- Plan For Your Discovery: Analysis & Inventory To Define Project Scope
- Plan For Compatibility
- Plan Your Target Infrastructure & Platforms
- Plan How You Will Design, Build, Test, & Manage Your Gold Operating System Image
- Plan Your T-(minus) Timeline
- Plan Your Deployment Ring Methodology
- Plan For Increased User Engagement
- Plan Which Software Tools Will Best Support Your Migration Efforts
- Plan Your Deployment Logistics
This process corresponds with our customizable WaaS project plan template which you can download.
Here is each step of the process mapped out in our Work Breakdown Structure for an efficient Windows 10 Servicing:
So let's look at each step in more detail:
1. Pre-Cycle: Project Framework Definition & Set-Up
Before you even get to the first step, some strategic decision making as well as preliminary planning and project setup work is required. This is a prerequisite before entering the continuous upgrade cycle. Please note: If you have already managed your initial Windows 10 migration using Dashworks, 95% of your preliminary planning and setup work is completed and you can skip this step barring some minor adjustments.
As for any larger IT Transformation project, I recommend you start by "Planning for the Plan" to determine the basic parameters of your Windows-as-a-Service management cycles. One of the biggest decisions you will make is your general Service Channel Retirement strategy by picking one of the following options:
- [Not Recommended] Migrate all devices on the Long-Term Servicing Channel. This is not a recommended or very common choice, but some companies are considering moving all users on the Windows 10 Long-Term Servicing Channel which does not require any updates for 10 years. This way, they do not have to upgrade until they are ready — which could be in a few years time. Since Microsoft's impressive security improvements are a key driver to adopt the new OS, this seems a poor choice.
- [Microsoft Preferred] Upgrade all devices to every new version as soon as possible. Microsoft recommends that all devices should be upgraded as soon as the new feature updates are released every six months. Many larger organizations don't feel they are able to keep up with the workload, so this might be better suited for smaller organizations.
- [In Some Cases Recommended] Skip every second update. Larger enterprises that struggle to manage two full update cycles a year have taken the approach of skipping every second feature update (e.g., 1709 would go straight to 1809). While this buys them one year to do a full upgrade cycle, it potentially puts them at risk to have unsupported devices for months if they cannot achieve the required velocity.
Whichever strategy you follow, I believe the safest and most manageable deployment option is to use a phased rollout approach. This requires your organization to be split up into Deployment Rings and often leads to parallel deployment streams, but with the right tooling and tight management, this results in a well-oiled machine.
After these big decisions are made, you will need to create a project plan (think SCRUM meets small, iterative Waterfalls), get preliminary executive and business unit buy-in and budget approval, as well as initiate your project and create your team. You might already have a dedicated Business-as-Usual team who will exclusively handle your service management for Windows 10 and Office 365, but if you don't, you should plan on that now.
2. Discovery: Analysis & Inventory To Define Project Scope
It seems counter-intuitive to start with analyzing and creating an inventory of all in-scope hardware components and applications if you are managing them in a rather fluid Evergreen IT state — but it's actually more important than ever to have an exact understanding of where each of your objects is in its lifecycle and in relation to each other.
This is true for the current, as well as for the target state of your environment which requires a central command and control platform that provides you with real-time insight at a push of a button. Not doing so can result in major scope creep, delays, ballooning costs, as well as business disruptions and overspending for licenses.
In addition, you will need to determine your SCCM version and support requirements for all in-scope devices. As soon as the new update has been published into the Semi-Annual Service Channel (usually, this will be in April and October), you should roll out the service update to your first deployment rings (Targeted) and gather and document results.
3. Plan For Compatibility
Once the previous step is completed, you know what you are dealing with and you can create your in-scope deployment lists. But you don't just want to jump right in. Now is a great time to look for improvement opportunities.
Just as you would do with a big bang migration project, I recommend strongly that you run your application estate through a categorization, normalization, and rationalization exercise to minimize the number of applications to start with. One of our customers was able to retire 72% of their apps that way! To do so, ask yourself:
- How is my application inventory currently stored and is there a way to store it centrally?
- Which applications are not relevant for this project and how can I identify them?
- What are my criteria for categorizing applications for rationalization (e.g., retirement)?
- Should application usage be a factor in deciding an application's future and if so, how will I determine it?
- How will I manage the operational and user acceptance testing? Can it be automated?
- How does an application's licensing status play into this?
- Which applications are suitable for virtualization and how do I determine their performance footprint?
- What are my target state application packaging/delivery platforms (local/MSI/AppV)?
- How do I determine my application owners?
- How will we handle the application testing and sign-off process?
- Where will we manage the master and rationalized applications lists?
- How will I track application packaging workflow and readiness to migrate?
- How will I refresh my application data into the project?
- How will I manage the deployment of applications to my users?
These are just a few questions to get you started. Once your applications are normalized and rationalized, the remaining should be centrally managed and properly tagged by impact (e.g., business critical, low risk).
On a continuous basis, you would ideally run all of your higher-impact (or even all of your) applications through a quick automated re-certification test for each subsequent update cycle. This enables you to cut down the numbers of manually tested and repackaged apps to an absolute minimum by determining which apps are compatible with the new platform right away. This way, you will be able to tightly manage your apps in an Evergreen methodology.
Furthermore, you will need to assess your hardware and user compatibility. With all three cornerstones in place, you can identify your deployment rings.
4. Plan Your Target Infrastructure & Platforms
Because of the much faster pace of upgrades, it is absolutely critical to plan adequately for a well-designed target infrastructure and platform to manage your Windows-as-a-Service as well as other assets (e.g., hardware, Office 365) from. Because your target infrastructure will most likely be a hybrid mix of on-premise and cloud solutions, virtual machines, mobile devices and stationary hardware, you will need to get an accurate understanding of your goal numbers for each user and migration type. This allows you to size your infrastructure correctly as well as be flexible as things change.
Most new Windows 10 feature releases will require upgrading your desktop management infrastructure (e.g., SCCM). But you should also continually look at your deployment technologies and supporting systems, your asset management processes, improve the health of all your systems, as well as centralize your app installation source and management in an enterprise app store. The healthier the environment you start off with and the better the management processes, the better the outcome and the easier your Evergreen IT management will be.
Your planning should include a way to:
- Continually assess the status, health, and compatibility of all components as well as map their connections,
- Support end-to-end processes with as much automation as possible,
- Test and remediate applications using smart workflow-driven automation, and
- Offer self-service deployment and automated communication wherever possible.
5. Plan How You Will Design, Build, Test, & Manage Your Gold Operating System Image
One of the biggest challenges for regular migration projects was getting the gold image built and tested fast enough to avoid having new patches and hotfixes that would render the newly created image already outdated before it was released.
Since now the clock is ticking even faster, you must have a clear vision of what to include (e.g., drivers, configuration, security products and settings, applications, policy and profile settings) and how it will interact with your end state user environment. In addition, decide on a technology to manage your image that allows you to make amendments where needed. Doing so will make it much more sustainable for the future.
As enterprise IT environments become increasingly fragmented, building a good-enough gold image becomes harder as you can include fewer and fewer applications. For example, Microsoft has recently announced that Office 2019 will not be delivered as an MSI, forcing you to consider other ways of system update.
Finally, be sure to fully test your image and all of its configuration against all types of in-scope back end infrastructure.
6. Plan Your T-(minus) Timeline
Because of the many different dependencies, procedures, and processes required to support such a complex undertaking, time frames are often underestimated and expire with disastrous results. For example, you may have to throw more people on the project to manually run parts of the upgrade that haven't been adequately standardized and cannot be automated. Or not understanding the dependencies will cause a spiderweb of bottlenecks — just think of how long it takes to refresh one piece of hardware and what is involved in terms of approval, shipment, delivery, configuration, and so on.
In order to be able to plan your timeline accurately, you will need to map out milestones and tollgates and the process steps to get there, how long they each take, and when they need to happen by. It is advisable to differentiate between different migration types as a rebuild usually is faster than a replacement, although in 90% of cases, in-place upgrade will be the norm.
Be sure to cover the end-to-end process from pre-migration tasks to scheduling and deployment and clarify who is doing what. Define a clear schedule of activities and document which tasks could be automated considering:
- How do you define your deployment capacity constraints?
- What change control will be required to manage the schedule (e.g., is there a lock down period)?
- Are there any business or company blackout dates that impact the schedule?
- How will the project team and business liaison officers communicate the schedule?
Again, these are just a few questions to get you brainstorming for your unique situation.
7. Plan Your Deployment Ring Methodology
With the introduction of Windows-as-a-Service and its bi-annual upgrades, Microsoft also introduced a new recommended way to roll them out: Windows 10 Deployment Rings. But don't worry — they aren't substantially different from the way most organizations rolled out migration projects. Deployment Rings are simply a way to strategically and dynamically stagger devices into a deployment timeline. The goal is to "reduce the risk of issues derived from the deployment of the feature updates by gradually deploying the update to entire departments."
To define your Deployment Ring on-boarding criteria, ask yourself what drives your schedule. Is it user readiness, application readiness, building readiness, or department readiness? What else could impact the readiness and schedule?
Ultimately, you want to come up with a methodology that allows you to group together as many users as possible that can be migrated as quickly as possible. For example, if 60% of your business users are using low-risk business applications that have been found compatible after a quick remediation step, it would be a quick win to tackle those first.
8. Plan For Increased End-User Engagement
Microsoft migrated almost all of its employees to Windows 10 in a matter of weeks, rather than months. The number one reason why this was possible is because of the high end user engagement (and of course their tightly managed, Windows-oriented environment). The point is: to be successful, you need to empower your end users to take an active or even proactive role in this ongoing transformation.
First and foremost, this means two things:
- Create a clear, automated path of communication tailored to each user's migration path that gets triggered at the right time.
- Offer intuitive, yet sophisticated self-service capabilities to gather or validate data from the end users directly; allow them to self-service their upgrade or choose their own more appropriate migration date.
Careful planning of the type, delivery method, frequency, and number of communications to your end users as well as your business liaison officers will greatly accelerate your migration and potentially improve the end user perception of the project.
9. Plan Which Software Tools Will Best Support Your Migration Efforts
Most organizations already have solutions for user directories, software and hardware management, application workflow management, request and problem ticket systems. But your Windows 10 Servicing Management will require a lot more than that. There are many different Business-as-Usual management tools on the market that provide excellent sources of project data and can solve a specific aspect of the puzzle. For example:
- Hardware/software inventory and application usage discovery
- Real-time data warehousing
- Automated communication and collaboration
- Application Packaging and Testing Automation
- Automated User Acceptance Testing and Tracking
- Deployment Triggering and Management
and much more. Undoubtedly, software tools can significantly accelerate your migration efforts, but if you are not careful, you can quickly end up with an expensive and equally clunky Frankenstein monster. Ensure that you have a centralized command and control platform that integrates with all required bits and pieces to ensure a clear end-to-end process.
[To learn more about which criteria to look out for when choosing the right IT Transformation Management tool, download our buyer's guide!]
10. Plan Your Deployment Logistics
Last, but not least, let's talk about planning the ‘how’ of your deployment logistics! Surprisingly, I have seen more projects that failed because the project managers bit off way more than they could chew, so careful planning is advisable! For example, overestimating the workload capacity your teams can physically handle in a given time frame, or misjudging the ordering process support, or the volume of orders and approvals required can lead to a project standstill!
If you are working with a third-party, like a systems integrator, your goal is to outsource the logistics and ensure that their sales pitch matches the delivery in this complex area. Another pitfall is that we often believe suppliers can just add more resources at a moments notice. But their fixed price business model needs to work at a certain capacity to make money. So realistically, you should plan this part of your project just as meticulously as all other areas.
Finally, plan on ‘how’ you are going to interact with your business liaison officers and define a service level agreement in the context of your project goals to ensure everyone knows what is expected of them and what they can expect in return.
Conclusion
While managing a Windows 10 Servicing update rollout process is much like a mini-Windows 10 migration, there is a lot of preliminary planning work and there are strategic decisions to be made to create a repeatable and scalable process. While with a project, there is a definitive beginning and end (= light at the end of the tunnel), with Windows Servicing, sloppy preparation will cement itself over time in inefficiencies, ballooning costs, and delays.
Want to download this article as a PDF?
No problem. Simply fill out the form below and you will be able to download the PDF version of the article right away.