In the past, we have shown you how to effectively plan for an enterprise Windows 10 transformation, Office 365 migration, and Windows-as-a-Service upgrade management. Because so many of you found these detailed step-by-step guides extremely helpful, I want to walk you through the planning basics you should consider when moving towards Evergreen IT and away from traditional IT management.
If you read any of our previous articles on Evergreen IT strategy or our Ultimate Guide to Evergreen IT Management, you know that it takes the right technology to manage these smaller, continuous upgrades as well as some organizational/internal change management and process adjustments. This can sound overwhelming, and most people get stuck right there. But with the right planning, this transition will be not only much smoother than you think, but will make your life down the road a LOT easier. So, let's get started!
So, let's dive right in.
A lot of people early on in the planning phase are under the false perception that Evergreen IT is an all-or-nothing kind of deal, e.g., you have to move your entire estate including hardware, infrastructure, and applications over at once — or Evergreen IT won't work. Actually, the opposite is true. If you wanted to switch over to Evergreen IT all at once, you would probably be so overwhelmed you would never see the end of the tunnel.
Instead, define your overall Evergreen IT roadmap and tackle it bit by bit. Therefore, the first step has to be to define your scope! You need to understand what is in scope for your initial and the next wave of your Evergreen IT service. Is it hardware? Is it applications? Is it the OS? Is it the infrastructure that supports it all? Is there something else on the periphery that you want to include? Keep in mind that you will want to start small and, like in agile development, chip away at your long list while constantly improving.
My advice here is to look for quick wins. For example, hardware refresh cycle management is relatively established and makes a great candidate for a first Evergreen IT project. It is something that you can get your arms around immediately — whereas sorting out shadow IT and licensing for software will be too overwhelming at first and may even need it's own project! Don't try to do everything at once — ease into it and expand from there.
After you have an idea of what your scope is, you will have to create a business case for it to get your budget and resources approved. Here, you have a few different options. For example, you could decide on how many versions you want to support and then manage your operating system or your applications to N-1, N-2, N-3, N-X. It simply depends on how far you want to go with the lifecycle management and how far back you want to go.
[How to create a water-proof Evergreen IT business case.]
Once you have got your business case in place, you will need to define your expectations for your Evergreen IT management team. For this, you will need to answer these questions:
While these questions sound mundane, thinking this through is a key step in determining how you will be managing the process.
Keep in mind that, generally, a larger organization doing an OS upgrade will assign at least one full-time project manager, whereas someone doing a couple of application rollouts could handle both those applications rollouts easily.
For some organizations this might be the most difficult step, while other IT teams get executive mandate to move towards Evergreen. Whatever your situation, I highly recommend not moving forward before accomplishing this step as Evergreen IT cannot be achieved successfully without executive buy-in.
Essentially, you will need to ensure that your business units are aware of and agree with the types of changes and velocity of changes that you are about to make — and, even more importantly, from a licensing and hardware refresh perspective, that they have got the budget to support keeping things in lifecycle. For example, there is no point in trying to force a Visio 2019 upgrade if the business doesn't have any money to do a 2019 upgrade or hasn't purchased maintenance.
Therefore, be sure to think thoroughly about the consequence of keeping these things in lifecycle, and whether or not people have really bought into that process.
Once you have secured executive buy-in, you are all set to move onto the next stage of the project: understanding your exact current state IT environment. Here is where you really want to understand how out of cycle everything is today.
This initial, yet full discovery phase is really important as you will identify where the quick hits are and decide which you should focus on.
Now that you know what you are dealing with, you need to segment each lifecycle piece (e.g., your infrastructure, desktop hardware, virtual machines, applications, and operating systems) that is in scope.
For each of those, you will have to build out your high-level process plans for each segment separately as, for example, a hardware refresh or a Windows 10 upgrade involves different requirements than, let's say, an infrastructure change. Then define a service level agreement that spells exactly what the business unit can expect of each of those processes and what they are required to do to facilitate the process.
This enables all relevant parties to be on the same page, manage expectations, and keep the process as smooth as possible. To be most effective, be sure your language is specific. For example, you could commit to keep SCCM on current branch within two months of it being released by Microsoft or keep desktop hardware within warranty or within warranty minus six months. This document essentially outlines your project plans on a high level.
Now, it is time to build your detailed project plans. In most cases, you can base each individual project plan on a well-defined, highly scalable, and repeatable standard project plan. Plan on managing one upgrade within each of those segments with each plan, e.g., upgrading from Windows 10 version 1809 to 1909. After each cycle, you can clone and tweak the project plan to prepare for the next round.
Based on that project plan, you can now identify how long the upgrade cycle should take end-to-end, what is going to be involved, the process that will support it all, and how to prioritize everything.
[Download our fully-customizable Evergreen IT Management Project Plan Template here}
While in the past, we managed one-off transformation efforts in one big-bang rollout with dozens, if not hundreds of outdated spreadsheets, hand-cranked databases, and lots of elbow grease in long night shifts, we need to rethink how we define our process here.
The secret is to
How are we going to identify the things that we are going to move and what priority order they should move in? This is where we can start to talk about, I guess, where Dashworks might fit in and how you then scope and start to action the data to manage the different upgrades.
Automation here is the key. The idea here is that you need a tool that allows you to click a button and it creates your project workflows for you based on a predefined project framework. Effectively, you really are just tracking readiness and scheduling rather than doing too much work on it. Of course, certain projects are still going to require a bit more of that testing, especially the OS upgrades, but the vast majority of the heavy lifting is done for you.
Now that you have planned out your processes, it is time to put all the other pieces in place that will allow you to deliver this ongoing service like a well-oiled machine. Essentially, plan to implement the supporting tooling, connect your resources, and translate your processes into an industrialized workflow that fits perfectly for your organization.
For more information on how exactly to do that, please check out our articles How To Accelerate Windows 10 Upgrade Rollout With Dashworks and Tool Requirements For Optimal Windows-as-a-Service Management.
Before hitting the "Go" button, we need to consider the maximum velocity we can achieve with our project. We can only go as fast as the fastest rate of change that people will accept. This will increase overtime as your users get familiar with the process and come to expect upgrades on a regular basis. While going too slowly can be a frustrating experience for everyone involved, going too fast too soon can also be counterproductive! After all, the last thing we need is more business disruption.
In addition to the change velocity, consider the volume of change. For example, if you have six different projects running at the same time and they're all having to migrate tens of thousands of machines:
Evergreen IT is a continuous improvement cycle and, as such, relies heavily on reporting. Live or near-time dashboards help you to stay on top of your thousands of moving parts — keeping you informed regarding where you are with your lifecycle management processes, how out of date your different segments are, what is scheduled to be done in the next 90 days, and much more. Plan on this being a constant cyclical review and continual process definition and optimization.
The key here is that it is repeatable and simple. If it is too complex, or BAU teams are not going to be able to handle it, your project is going to get stuck.
If you take one thing away from this blog post today, I hope it is this: While successful Evergreen IT management takes a bit of planning, it is based on a highly automated, almost industrialized process framework that — with the right tooling, executive buy-in and repeatable processes — will eliminate a lot of your tedious, manual maintenance workload.