Fixing the boom-bust cycle of desktop transformation
"IT hated the business, and the business hated IT" — that was the prognosis on the last major Windows migration in a tier one organisation we've been talking to. It's a common perception of desktop transformation — no matter how good a job we as IT do, any desktop transformation is going to be a relatively major distraction for the business versus their primary goal, creating revenue or providing service.
Of course, the same used to be said about virus and patch management. Not any more. Those items have, in the main, been dealt with by a combination of technology and process focus. It's rare to hear these days that a company spends the inordinate amount of time that we used to on such activities.
Let's wind back the clock. The slammer virus has just hit. It's a brand new virus, never seen in the wild and it's spreading. Corporate machines are getting hit by the millions per second. Our first answer as IT — turn all the machines off, stop the spread. Next, figure out a way to patch and update all the machines without further spreading the problem. It was a common problem, and it required focus. Why did it happen? What could we have done to stop it? How do we improve our processes to reduce the risk in the future?
With a combination of senior focus from IT directors, software vendors and businesses who put the cost into $billions, the problem got pretty much fixed. Tools can now put out an update in a matter of minutes across hundreds of thousands of PCs, anti-virus companies have improved their speed to market for definition updates, IT have put in fast, slick processes to get the patch testing done to reduce the vulnerability window and most importantly, Microsoft sorted out their patch release process and made it regular and automated.
There's an argument out there to state we that we haven't been applying the same levels of focus to desktop transformation, even though the risk and cost are potentially greater. Typically, the lessons learnt from past desktop transformations are forgotten, and we spend months re-inventing the process wheel. The people involved in those efforts have long since moved up the management chain, and a whole raft of new resources are bought in to make the same mistakes as their counterparts all those years ago.
It's a common story we at Juriba hear time and time again. My only conclusion is that because desktop transformation projects are generally such distinct, funded pieces of work, the people involved in them generally are not given, or more likely, don't want the responsibility to put in place more strategic tools and processes. Sure, the projects get delivered, but the legacy never remains. Therefore, we seem to live forever in the boom-bust cycles, where each new desktop transformation is a mass of new resource, technology, process and cost.
So how do we begin to fix this problem? Well, in my experience, the project team will clearly identify all those issues we've been living with in BAU, the process challenges, the system challenges and the efficiencies that could be bought with new tools and processes. What now needs to happen is for senior management to take those issues and assign them to the BAU teams to implement, maybe even using some migration project funding to implement them. After all, if you can improve the processes and tools during the project, that will surely make the project more efficient and save critical expense.
But here's the key piece. We know that Microsoft is committed to a new desktop OS release every 3 years. So even if organisations skip the odd operating system, we're destined for a cycle of 3-year migration, 3-year steady state in the largest corporates. We don't need the project team in the steady state years, but if we can implement consistent tools and processes in BAU that take the pain away from the migration planning, when we do need them, we shouldn't be asking them to reinvent the process wheel. This is the key to future migration success and the beginning of what we'd like to see as a new cultural way of thinking about migrations within BAU, something I'll be covering more shortly...
