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.
PHASE 1: Plan For The Plan
1.1 Define Your Scope
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.
1.2 Create Your Business Case
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.]
1.3 Assemble Your Team
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:
- What resourcing do you need to manage the scope of what you've agreed?
- Who are these people will you need and what is that team going look like?
- Do you have the required skills in house? If not, can you train existing team members or do you need to hire?
- Will you have a project manager? Or will your resources be aligned to certain mini project types or process types (e.g., one dedicated FTE running the OS while someone else is running a hardware refresh)?
- Will you create separate project pods or will one team run all of it?
- What are the resource capacities? Are there any long-term constraints (e.g., planned business unit engagement that might take away time from the on-going management) you need to consider?
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.
1.4 Get Executive Buy-In
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.
PHASE 2: Plan For Optimal Delivery
2.1 Initial Discovery
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.
- How much shadow IT do we have? How much application sprawl are we dealing with? How many unlicensed, blacklisted, outdated, or non-approved apps do you currently have installed? How much overlap is there?
- How much aged hardware do we have? What percentage of your estate is approaching the end of its lifecycle versus how many are older than that?
- How much is the OS aging? How many versions of the OS do we have rolled out? How many different images are we supporting for Windows 10?
- What are our currently in place processes to upgrade and cycle these things?
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.
2.2 Define Service-Level Agreements For Business Units
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.
2.3 Create Your Project Plans
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}
2.4 Plan For Automation Wherever Possible
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
- Define a scalable project framework that can be easily repeated and
- Is highly automated and implement it with tooling that allows you to
- Have real-time actionable insights into your estate to determine your path of maximum velocity in a central command and control center, while it
- Does the heavy lifting for you.
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.
Phase 3: Plan For Technical Implementation
3.1 Plan For Your Supporting Tooling
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.
3.2 Plan For Optimal Change Velocity
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:
- How are you going to logistically manage that?
- How do you ensure that you're not touching the same device over and over again, causing end users to lose productivity?
- Or how are you planning to avoid crossing processes somewhere?
3.3 Cyclical Reporting & Tweaking
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.
Recommendation
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.
