More than two years have passed since Microsoft announced its latest Windows operating system, Windows 10, and while this announcement created the usual buzz, some people might have initially had to read it twice. In the announcement, Microsoft dubbed Windows 10 "Windows-as-a-Service", making it the last operating system Microsoft will ever release. This means that instead of releasing a new version every couple of years, the software giant will publish two feature updates per annum and monthly service updates — a complete departure from the way Windows was deployed in a business environment until now.
The Microsoft marketing machine did everything to convince IT pros and executive management alike that this new model is a good thing — which, without a question, it is as it smooths out the migration workload, reduces learning curves with end users and keeps the operating system more secure as updates happen on a more frequent, proactive basis.
They published impressive statistics and case studies, including the story of how Microsoft itself migrated over 90,000 employees within weeks rather than years. They partnered with Forrester to shine more light on the potential cost savings an enterprise would accrue by migration, and much more.
But despite these marketing efforts, enterprise adoption has not been as fast as anticipated. To find out what is holding them back, we asked more than 170 IT pros what they are most afraid of when it comes to Windows-as-a-Service management.
The majority of respondents said they feared potential business disruption (31.5%) and the frequency of updates (29.6%), while application compatibility (20.9%) and scheduling & managing (17.9%) trailed behind.
These types of concern are to be expected given where most IT departments have come from, but when you start talking to the IT professionals responsible for managing the as-a-service model, you find out that the root of the problem lies a lot deeper than just the methodology change. So, below, I want to dive into the five most common concerns or roadblocks which explain why Microsoft has such a hard time getting IT pros onboard with their servicing model:
Defining A Business-as-Usual Project Scope
Traditionally, IT dealt with a massive desktop OS migration project every 3 to 5 years. On average, it took them about 124 man-weeks to roll out an operating system enterprise-wide using the custom-developed, hand-cranked databases or spreadsheets they used for previous migration projects.
Since these tools did not allow for actionable insight into the current state of their IT environment, the rollout process had to be dealt in some other logical manner, e.g., by rolling out specific locations or departments first. This was expected and accounted for, and an upgrade lifecycle of several years accommodated that fairly well, even if it was an inefficient, lengthy, and more than frustrating process. At least, there was an end in sight at some point.
Now that Windows 10, Office 365, Windows Servers, SCCM, and many other technologies have upgrade cycles that span from a few weeks to several months, IT has to figure out how to define and deploy a servicing strategy that will enable them to roll out updates to tens or even hundreds of thousands of end users in six months or less. This big-bang project approach and the tools they previously used are completely inadequate when managing deployments on such a scale at such a pace.
Therefore, the traditional way to manage migrations is being replaced by a more liquid way to manage and improve the ever-changing state of your IT: Evergreen IT or Business-as-Usual. However, to manage anything, you need to be able to measure it first. And to manage your IT in this agile way and to be able to determine the scope of your "Business-as-Usual project", you have to know exactly what your IT estate looks like, be able to understand the readiness and compatibility states of your hardware, applications, etc. and prioritize rollout schedules accordingly.
Sidenote: Microsoft's marketing promotes the idea of project-less Windows 10 Servicing management, the deployment of subsequent Windows 10 feature updates. For most organizations, this is a dangerous assumption that has gotten more than one IT project manager in hot water. If you are considering this, I recommend you read this article first.
Getting Business Buy-In For Faster Upgrade Cycles
Once you are able to determine the scope of your Windows 10 update cycles, you need to get the business units on board — which isn't easy! While end users are pushing for the new operating system that they have been using at home for the past two years and are getting excited about the new enterprise productivity features that come with Windows 10, many line-of-business managers and executives are hesitant in fear of the business disruption and havoc these continuous updates might cause.
This is understandable. They also have been part of past OS migration projects and they know the drill — the constant back-and-forth to figure out the best migration dates; the application testing and remediation; employees without their laptops roaming the floors trying to find something useful to do while they wait for IT to be done with their devices; IT walking the floors for days, checking setup configurations; lost productivity because of countless calls to the IT help desk because something isn't working as it should; the steep learning curve that comes with a new operating system, and so on and so on.
Now, with this faster pace of two update cycles a year, they are even more hesitant. And who can blame them? Without a strategic approach and the proper tooling, the faster-paced rollout could be a complete disaster! But this is also an opportunity. Explain to your business unit managers and other relevant stakeholders how you will manage this process differently. To turn their fears into excitement, show them how:
- They will be involved and can use executive dashboarding to be in the loop at all times.
- They can expect full transparency, clear insight, and accountability from your team.
- Their employees can play an active part in the rollout process by using the self-service tools to pick a convenient migration date within the bounds of your capacity, choose a new device if they are eligible for a hardware upgrade, validate data and add context around application usage and much more.
- Communication will be automated and streamlined to minimize a constant back-and-forth and to engage the employees early on in the migration process.
- You will be able to migrate the lowest hanging fruit first — allowing for swift progress.
These are just a few pointers to mention, but based on your approach and tooling, there will be more. No matter how you are planning to go about this project, it pays off to be as transparent and upfront as possible to minimize any surprises down the road.
Business-As-Usual Function & Budget
Most IT organizations already have something that could be called Business-as-Usual next to their project teams. These are the people who "keep the lights on". This function of IT is purely operational and includes daily operational tasks such as applying desktop patches and updates, managing support help desk tickets, or scanning error logs and fixing bugs. They are in a constant state of catch up — without ever changing status quo. The transformation, and sometimes innovation, only came from dedicated project teams — until now.
With this faster cadence of updates and the need to improve your IT environment on an ongoing basis in much smaller, more continuous upgrades, these responsibilities need to change. But as scary as this sounds, keep in mind that organizations are spending 60-80% of their entire IT budgets on purely operational tasks. Freeing up a large chunk of that budget through strategical Business-as-Usual activities could result in an enormous opportunity to drive innovation as more resources and money are available.
To do so, you will need to create an embedded function within your Business-as-Usual team that will handle the responsibility for the ongoing application packaging and testing, managing the scheduling and deployment as well as the end-user training and hand-off. Most likely, you will want to use your current project resources to fill this gap. However, it is critical to understand that BAU and project management require two very different skill sets. It also helps to create a roles and responsibilities matrix to show who needs to do what and when to keep pace.
Hand-in-hand with changes in your organizational structure, skills, and team identity goes the distribution of budget. Going forward, you will need to decide how you want to handle the responsibilities of your Windows 10 project team. Do you keep them as a separate entity or merge them into your Business-as-Usual team? Based on that decision, you can then determine how you will spend your budget.
Defining End-to-End Timelines & Workflows
Another roadblock for Microsoft in getting enterprises onboard with the idea of updating their Windows OS twice a year company-wide is that they simply have no clue how to get it done.
As I mentioned earlier, OS migrations were handled very differently in the past. Leaving their trusted spreadsheets and hand-cranked databases behind and entrusting the success of this project and therefore your job security to a completely new way of doing things isn't easy for a lot of seasoned and experienced IT project managers. But even if you are willing to throw these archaic ways overboard, you still might not know where to start.
Having helped to ready more than five million assets for successful IT Transformation, I know one thing: Setting up a repeatable process from the get-go is the secret to success! To help you define your end-to-end timelines and workflow, I have created a fully customizable Windows 10 migration project plan.
Because every subsequent update is essentially a mini-Windows 10 migration, you can adapt this project plan to help you plan your Windows-as-a-Service management process. Just cut out the first steps. Once your project management tool is connected to all your relevant data feeds, your project framework is in place, your automated email communication, your dashboards and reporting as well as your self-service portals are configured, you can skip right into your readiness, orchestration, and deployment using deployment rings.
Building A Repeatable WaaS Update Process
Once you've defined your repeatable deployment process, you will need to put the right tooling in place to support your new strategy. There are mainly four things to keep in mind:
- Continual assessment. Your tooling must allow you to have constant insights into the state of your applications and hardware. You will need to have accurate, up-to-date information on their release and end-of-life dates, application compatibility status and available upgrade paths, Windows 10 Servicing options, and much more to make informed decisions.
- Application testing & remediation workflow. Since you might need to test, package and remediate lots of applications every year, you will need to have an intelligent and automated workflow in place that will not only route your product owners and application packaging team through the process as efficiently as possible, but also streamline the workflow. For example, you could implement a risk rating system that could help you prioritize which apps to test when. In addition, you could run them through an automated re-certification workflow to cut down the number of apps to be tested by an actual person.
- Capacity constrained Self-Service deployment. You can leverage your end user's enthusiasm for new technology and give them the option to request their migration whenever it becomes available. This not only means more numbers on the board faster but also ensures project success as end users who had an active part in a project are less likely to resist change and more likely to perceive it as successful overall.
- End-to-end process support. Once all the pieces are in place, you will need to ensure that you have a team of dedicated resources to support your process from beginning to end by deciding (and implementing) the who, the what, the where and the when.
There is no question that many enterprises are motivated to move to Windows 10 because of its better security capabilities, tighter cloud integration, productivity improvements and other features that come with the enterprise version of the OS. The hesitation to make the move is palatable when you speak to IT professionals in medium- to large-size companies.
But whilst in past years, enterprise adoption was slower to give the OS time to mature on the market before rolling it out enterprise-wide, they are now stalling because they are wondering what happens after the initial migration. In other words, the resistance that Microsoft feels when it comes to the adoption of its new Windows 10 Servicing model is less rooted in the concept or the available update options than it is in the anxiety over how to deal with the hamster wheel of upgrade cycles.
As it is a complete break from what IT organizations are used to, IT teams will have to strategically plan for a repeatable process fueled by actionable and up-to-date data. They need to integrate their former project teams into a Business-as-Usual team that will drive continuous improvement, using adaptable project frameworks and adequate tooling, such as Juriba's IT Transformation Management platform, Dashworks, to keep up with the pace.