Last week we covered the available project ‘levers’ to help move off Windows XP prior to end of support. This week we look at project stream concurrency, profiling your workforce, and – the elephant in the room – application remediation.
One of the challenges that we come across regularly is the length of time it takes to migrate to a new desktop. There are typically two main reasons for this: 10 (or more) years of neglected application lifecycle management (which we will come to shortly), and running the migration project like a large sequential task list of activities. Assuming that you have more than just one person assigned to your project, there are some key project activities that can be run in parallel. We will cover this as we look at each stream.
When Microsoft Consulting Services puts together a desktop modernisation project, we undertake five distinct streams of work: workforce analysis and design, application strategy and remediation, image creation, user experience personalisation and infrastructure preparation.
First off the rank is workforce analysis and design. Assessing and understanding who your project is designing for is undoubtedly the most neglected part of many Windows migration projects. Beyond simply collecting requirements, workforce analysis examines how your organisation’s staff members work and use technology to support their day to day activities. Time spent doing this work at the beginning of your project is essential to ensuring that the right technology is deployed to the right staff in support of making their jobs easier.
The most common role types, or personas, that we tend to see are office based, mobile, task, contract and home workers. In addition each industry has its own distinct persona types with specific requirements – for instance, clinical nurse or airline pilot. The technology requirements to support each persona can be very different. Once the needs of different user groups are understood, we then document the overall project goals, sequence of tasks and design decisions across all streams of work in the form of a high level design. Importantly, start your design process with the end user of the technology in mind.
Now the hardest bit: application remediation. Without a doubt this is the most expensive and time consuming part of any Windows migration project. It is also the most common area where we see organisations struggling. These are the key problems: application ‘sprawl’ or years of limited application lifecycle management resulting in a huge application portfolio to deal with, lack of understanding from IT and the business of which applications are essential to keep the organisation running, historic decentralised application procurement and widespread administrative rights for staff to install their own favourite software. If your organisation ticks some or all of these boxes, don’t worry, you are in good company.
There are some practical levers that you can move to increase the velocity of your application remediation. Firstly, work with the business to identify and prioritise all critical applications and the business owners of those applications. This effort can be politically challenging but is critical to the success of the migration. These applications should ‘just work’ on your new Windows desktop and will require more focus for testing and remediation. They are also the applications which inspire the ‘please explain’ meeting with your CEO if they don’t work following your roll out!
Secondly, reduce the application count. Consolidate different versions of the same product and then work with the individual business units to consolidate different software products that do the same function. Do you really need ten graphics editors in your environment?
Thirdly, look for quick wins where you have personas or business units that have similar application needs. The migration project can continue with these staff while you continue to work through your other applications. Crucially, doing this also means that the project isn’t burning through its budget without having delivered any direct value to the business.
Lastly, try not to get wrapped around the wheels of full spectrum testing across every last application in your environment – great is the enemy of good. Deal with business critical and high usage applications, but look to more lightly test less important applications. Many of these commodity applications will ‘just work’ and those that don’t (and won’t cause business disruption) can be reactively remediated. Microsoft guru Chris Jackson’s blog is a great source of information on structuring your application remediation approach.
If you need to accelerate application remediation and have ‘spare’ project budget then this is a good activity to partially (or fully) outsource to an ‘application factory’. Most major system integrators and vendors (including Microsoft) are able to provide this service.
If your organisation has not yet started application remediation then you should establish some simple principles, a list of prioritised critical business applications and then kick off this stream immediately… or sooner.
Next week: Migrating off Windows XP – getting to the finish line.
Terry Chapman works for Microsoft New Zealand as an Architect in the Microsoft Consulting Services practice. Over the coming weeks Terry will cover some of the most common questions and challenges that Microsoft comes across while talking to NZ organisations about moving from Windows XP to Windows 7 or Windows 8/8.1.