Piloting Windows 7 - Part 1: Intro and Targeting Users for the Pilot

  • Article

We once again welcome guest blogger, Jeremy Chapman.

Now that I’ve written the most informal white paper ever published about operating system deployment, I’ve been inundated with requests to talk about piloting Windows 7. There were some excellent resources written in the Windows Vista timeframe from MVPs, but as they have pertained to Windows Vista and not Windows 7, not many people are finding or using them. In truth, the concept of piloting an operating system isn’t really unique by operating system version and I can say with a high degree of confidence that just about everything you read in my next couple of posts will be relevant for Windows XP, Windows Vista and Windows 7.

Before I came to Microsoft, the IT organization I worked in was in a constant state of piloting something, usually software, but sometimes the occasional operating system. Piloting is about putting something through its paces without exposing yourself to much risk and I think most IT organizations are doing a lot of this. Whether a new application is rolling out or another is nearing end-of-life, I was always testing something and my guess is that you are, too.

Piloting an operating system is like a mini deployment, you do roughly the same steps you would in a full-blown deployment, but you don’t worry about process polish or scalability as much. Combine that with specific targeting of representative and willing test subjects, and you have a pilot.

Targeting Your Pilot Users

One of the first things you do when piloting applications or operating systems is figure out who the best people are to test and report back issues. There is no perfect science to this and the general rule of thumb is to find communicative people who are somewhat self-sufficient and can take the occasional software or configuration glitch. There are a few elements to consider a group of people to pilot Windows 7:

  1. Users who are enthusiastic about new technology. I’m one of these people and if you can’t identify them easily, chances are their colleagues can.
  2. Users who can easily be rolled back to previous state or have a couple devices to use simultaneously. For roll back, this usually means proximity to your IT staff in case anything is not working. If they can use multiple devices, I would recommend against road warriors – unless they have small form factor devices.
  3. Users with Windows 7 compatible hardware. This is getting easier than with Windows Vista or even Windows XP at the time it was shipped. Most hardware produced in the last four years will be fine – even low end devices with 1.6 GHz processors and 1-2GB RAM may be sufficient here.
  4. Users with a representative set of applications. You’ll want a decent cross-section of user roles, the applications they use and levels of technical savvy. If you have less technically savvy users in the pilot, then the part of rule #2 applies for keeping especially those users within close proximity of IT resources.
  5. Users who will take the time to provide feedback. This is where tech enthusiasts alone may or may not suffice. I tend to work through issues myself without complaining to IT, but you actually want people who communicate issues before trying to resolve or reverse engineer issues themselves.

 
I tend to prefer opt-in models, where the user feels in control. In this case you only need to set guidelines around communication and their involvement in the process. What also seems to be working lately (as smaller devices keep getting less and less expensive) is giving pilot users dedicated notebooks with Windows 7 pre-loaded. This is actually new to Windows 7’s release timing, given current pricing for budget devices. The theory here is that the specs on these machines are far less than what is normally in production, so a user satisfied with these devices will be more satisfied with an even more powerful device later.

With pilot users selected, we will move on to the next topic around pilot project planning in the next blog post.

Stay tuned and thanks for reading,

Jeremy Chapman