Almost two years ago, we published an article called "How To Staff Your Windows 10 Migration Team Properly" which walks you through the required team member roles and necessary skills for your Windows 10 Transformation project. Now that a significant number of enterprises have at least begun, if not completed, their migration, we thought we should have a look at how your team roles need to change to adapt to a continuous Servicing Update management model going forward. For many, this function will be assimilated into the Business As Usual team, a change which could have major impacts if not managed correctly.
There Will Have To Be Changes
Moving large scale operating system rollouts from a project-oriented team to a Business-as-Usual structure requires some subtle changes.
First and foremost, irrespective of who delivers it, the success of your Windows-as-a-Service update process depends upon the alignment of your people, process, and technology. You cannot put sophisticated IT automation tooling in place if you do not understand fully the end to end readiness, scheduling and deployment processes to go along with it. Equally, without the right skill (and mind-) sets of your people, the best processes and technical infrastructure won't do you any good as it is the people who enforce the process and use the technology.
Secondly, your Windows Servicing management process must be repeatable and industrialized as much as possible to ensure a streamlined and fast delivery. The entire feature release change must be mapped out from the initial Microsoft announcement through to device deployment. This process has to be defined and agreed upon with the business units, application owners and other key stakeholders or this isn't going to work. It requires a special kind of team — one that isn't stuck in the ways of the past as traditional IT management practices aren't adequate to handle such a high velocity of change, but also one that has project management experience and skills.
Thirdly, when compared against a full scale Windows 7 to Windows 10 project, your need for resources will significantly go down — even if it isn't as low as Microsoft has you believe. As I go through the roles below, I will point out which can be reduced or even eliminated entirely. But after a few iterations, you should be able to establish a smoothly running machine that is operated by as few people as possible — freeing your team up to drive innovation and contribute to tangible business results.
Lastly, I want to send ahead one bone of contention: whether or not you will need a dedicated function with clear responsibility and accountability. While some organizations try to do away with projects, we do recommend having a core team that is organized almost like pods in a SCUM project with a dedicated budget and clear deliverables. This means your Business-as-Usual team has to start thinking like a mini-project team and you have to carefully put processes and supporting tooling in place that allow people who aren't skilled in project processes to manage each rollout phase correctly.
Your Windows-As-A-Service Team
Now, let's have a look at the team members in more detail:
- Key Stakeholders. Your key stakeholders will hold the same role as in your initial Windows 10 migration: a high-lever steering committee whose responsibility it is to ensure that the continuous rollout meets all pre-defined requirements. In addition, your key stakeholders will provide you with sponsorship and accountability for escalation. While executive support for a migration project is important, is is absolutely vital that your stakeholders are bought into the fact that you will need a budget. Stakeholders must communicate with peers to let the business units know this is coming, and what to expect. Once this is an established and proven process, the time requirements for all stakeholders involved will be minimal.
- Team Managers. Every project needs a number of manager specialties, e.g., Application Managers. Communication Managers, and Deployment Managers. These roles are just as applicable in the WaaS context as they have been with the initial migration project, but here they need to be more aware of this going on with the entirety of the project. Of course, you will also need reporting and dashboards to help prioritize and track workflow..
- Processing Infrastructure Experts. Having excellent process and infrastructure expertise on your WaaS team will be invaluable for the efficiency of your rollout and these guys (and girls) are responsible for your end to end solution design. If you have some six sigma type experts, then their input with the first couple of iterations will be invaluable. While this role is critical, over time, the resources can be reduced to a minimum.
- Engineering and Software Development. While you still have engineering and software development on your core team, your needs per upgrade are substantially lower compared to a big-bang migration. Their responsibility is to get your core image built out, certified and ready to upgrade as soon as possible after the new Windows 10 version gets released. They apply all your organizational settings and making sure everything works and is robust. In addition, your team could be impacted by certain infrastructure decisions as you upgrade, e.g., you might decide to stop supporting a certain version of hardware, upgrade your SCCM or certain applications.
- Application ID & Testing. In contrast to the Windows 10 migration where the main focus was on application discovery and packaging, your team needs to now focus on application identification and categorization as well as testing. The primary objective here is to get to a state where you can quickly look at your application list, categorize it quickly, and then decide: "Do we test it or not?" Then, put it through a particular workflow. Since this will be a major bottleneck, be sure to set up an automated, repeatable process with clear application categorization.
- Business Unit Liaison & Application Owners. While the role of the business liaison should still be required, it might change in a BAU setting. My suggestion is to go to each business unit and recruit a few evangelist candidates and application owners for the first three or four deployment waves (wave zero to three or four) rather than having each feature release go out to every business. Giving your business units the option to put the appropriate candidates in the appropriate development rings gives the business responsibility and you accountability if there are any delays or bottlenecks. Because their primary job is to set the standards for their business unit, this will help set you both up for better collaboration and communication.
- Logistics Coordinators, Communications Experts, and Migration Schedulers. Traditionally, the logistics coordinators and schedulers have the majority of the workload as they keep things flowing at a set pace and ensure migrations are pushed to capacity of the team. Now, with a repeatable process framework and an industrialized process, their workload should reduce significantly. You should be able to just fire up the next framework and everyone knows roughly how it should run. Because there shouldn't be as much change as for the big transformation projects, you should also require less schedulers, especially if a default deployment ring configuration is established.
- Deployment Engineers. Your Windows Servicing should be laid out to be "Zero-Touch" as far as possible — minimizing the need for deployment engineers. You still need the role though because there will always be things that change, e.g., a larger number of hardware replacements might be due in a particular upgrade cycle. Equally, focus will still be needed on those first machines where higher risk is assumed on the rollout of things not working as they should.
- Procurement. Just as with a one-off migration, procurement isn't a dedicated role, but an important function in the logistics chain. As you set up your project to be a mainly automated workflow that triggers certain other workstreams, having a dedicated point of contact and liaison with the hardware and software vendors is invaluable.
- Service Desk. While your project team is often responsible for any service tickets in a migration project, in WaaS your service desk support staff will be highly impacted by anything that goes wrong. Therefore, it is advisable that they have some involvement in the scheduling and understanding of what's going on.
The Crux Of The Problem: Who Is Ultimately In Charge
As you might have noticed, the traditional program manager role isn't listed above. That's because, if you do it right, you shouldn't need a project or program manager. Ideally, if you are new to Business-as-Usual management, you will probably want to have one around for the first couple of iterations while processes get defined. But as your rollout process becomes better, the need for a project manager per se goes away.
But that leaves enterprises with a huge problem: who is ultimately in charge here?
Many organizations have started to realize this and are trying to fill this void with a newly created position, "Workplace Manager". He or she would interface with IT, executive stakeholders, business units, HR, procurement, and other relevant teams. My first role at JPMorgan was that of a "Product Manager" and I was responsible for managing desktop standards. The role of the Workplace Manager seems to be assuming that type of responsibility for Windows-as-a-Service.
But where does this role reside? Whom does he or she report to? Does this role own the budget for the entire Win10 Servicing process? There are so many open questions that haven't been universally answered yet. This creates a big enough problem that some organizations are considering hiring service integrators that would run their Windows 10 Servicing on their behalf because they feel they don't have the in-house skills and organizational setup to mange it.
If you have a solution you would like to share with us, please feel free to share in the comment section below! We would love to hear it and it would help your peers tremendously.
