The Top 7 Lessons Learnt From Your Windows 7 Migration

Let’s talk for a bit about project management methodology. In any framework worth its salt, the end of any big project has a closedown phase. The key deliverable in this phase is a document which outlines the lessons learnt, and provides guidance on how to approach a similar project next time.

I’ll wager that most of you will answer ‘never’ to that question. But why is it important?

Let me take you back a few years. The company I was working for had just completed a huge NT to XP migration. The program manager for EMEA initiated a project review. We held our breath – the project had not run particularly smoothly. What was he going to say?            

1. Scope Creep: Whilst the project team was focussed on the NT migrations, the wider IT organisation wanted us to fix everything that was wrong with the environment that had built up over the last 7 years. These changes in scope reduced our ability to deliver migrations, and in some cases put the program back months for certain business units. We should have had a clearer plan of the infrastructure dependencies and realistic timelines before we even started thinking about migration planning.
2. Business Engagement: We should have engaged the business much earlier on in the process, clearly identifying their responsibilities and part in the process. We should also have identified earlier (during discovery) where business units had dependencies which were outside of the scope of the program (e.g. Equity application releases, end of year etc).
3. Lack of end-to-end Process: We should have identified, documented and outlined end to end responsibilities in our T-(minus) timeline at the start of the project. Inefficiencies were the result of project resources not understanding the process, or their role within it. A clear end to end process diagram would help establish the steps and areas for efficiencies to be gained such as automation.
4. Lack of Tooling: We had no central tool to inventory, analyse, prioritise, ready and schedule the migrations. As a result, hundreds of spreadsheets needed consolidating weekly to build a picture of where the project was at. This required an additional team for reporting purposes, called command and control. Further, it meant the project could not target the ‘best’ users for migration based on readiness rather than targeting sub-groups one by one, irrespective of how complex they might be. We could have saved significant time and dollars with an appropriate project tool.
5. Application Management: We did not start the process early enough. We assumed that the businesses would know which applications are important to them, which they used, who owned them, who the primary contact was, and who could provide the technical detail and test the application package when it was ready for UAT. In reality, none of this was true, leaving the project with a huge discovery and validation process, and a lack of test resource for the applications after packaging. Consequently, the applications team were under constant pressure, yet did not have the information required to maintain a priority list, report back on progress or drive efficient migrations.
6. Business Buy-In: Many of the business employees simply were either not aware of, or not interested in the Windows XP program. The business did not felt bought in to the project, and saw it as a distraction rather than something which was going to deliver significant value. This meant significant apathy across certain units which meant the program had to undertake a huge marketing effort to establish some user demand. The program should have been sold top-down, put into the company objectives, and business units driven to deliver their tasks quickly and efficiently with clear owners and accountability for any delays. Only when the product management team put in place charge back incentives on XP billing rather than NT billing did we start to see some clear buy-in and business unit demand.
7. Dedicated SWAT Team: It soon became clear that BAU staff did not appreciate the urgency required in a large migration project, especially where the infrastructure is concerned (software/OS delivery). Therefore, mid-project a dedicated technology SWAT team was created with access to the infrastructure to be able to fix issues immediately (governed by the BAU teams). This meant a much quicker post-migration response and helped to improve project perception significantly. 

Sound familiar?

It is a slightly sad state of affairs that the key lessons learnt in Windows NT to Windows XP are probably almost identical to those for Windows XP to Windows 7. But did we learn, or did the problems just never go away?

In the last ten years IT in the desktop space has undergone some radical transformation. The infrastructure that supports us is light years away from when we last attempted a project like Windows 7/8 migration. So why, from the surface, does it seem like so little has changed?

Conventional wisdom would suggest that a successful project involves the right mix of people, process and technology. What we have learnt is that these projects often become much more than what was originally scoped, and as a result, the increase in complexity drags the timeline, cost and resource drain up significantly. The old adage is still as true now as it ever was. “Fail to plan, plan to fail”.

Let’s be clear. We may have suffered again during your recent Windows 7 migration, but if Windows 8 or 9, desktop or application virtualisation, or indeed any other project which is moving technology from A to B is upcoming, address these top 7 points now. Great planning and preparation = smooth and consistent project delivery. Let’s try and break this cycle (and if you use Juriba’s Dashworks to help do it, then even better).