What not to do when deploying Windows 7

April 8, 2014 is coming up fast. Too fast for many IT shops. That’s the date when Windows XP extended support ends and Microsoft will stop updating the OS. Many organizations are finding themselves in a bit of a time crunch to complete their desktop deployments before time runs out.

Windows XP will not suddenly stop working on April 9. It’ll still boot, it’ll still run applications, and it’ll still connect to the Internet. But it won’t get any more security updates and when hackers find and exploit holes and bugs in the OS, XP users and their IT support folk will have no avenue of recourse to patch the OS. It’s a very vulnerable situation that businesses and organizations don’t want to find themselves in.

Having spoken to many IT folks lately who are getting started or are in the midst of their deployment, here are my 5 things not to do for a successful and timely client OS rollout:

  1. Ignore the size and scope of the project before starting. Let’s just add to the project as things come up. So don’t assess hardware so upgrades can be planned. Maybe an Office upgrade should happen at the same time. How hard could that be since the OS is being updated anyway? Let’s ignore the fact that the company uses macros and depends on Access databases which will need to be tested. April 8, 2014 isn’t a hard stop date anyway right? We’ve got lots of time for extras.
  2. Forget about doing a thorough assessment of your applications. Does it really matter that there are 5 versions of Adobe Reader on the floor, that the 3 different graphics packages could be consolidated down to one and that no one uses QuoteRUs although it’s installed on 50% of the desktops? Let’s just inventory the environment and test everything because we have lots of time and money to do so. Or let’s just assume we know what people are using and only test and remediate those applications to save time and money. Of course people may not be very productive after the rollout if we guess wrong but how bad could it be?
  3. Don’t consider who owns the applications. While the business unit may champion the use of some applications, we can save time by doing our own testing of the applicaiton. Regardless of whether we understand how people use the applications or what the business unit really needs we can decide if an application can, should and will be moved to the new environment. Consulting with the business just means more delays and we’re on a time crunch!
  4. Don’t put together a detailed project plan. Gantt charts are scary. Need I say more?
  5. Don’t worry about having solid technical leadership. Microsoft is pulling support and our executives are behind the project and expecting timely results. We’re experts on our IT systems so we’ll figure it out even though we haven’t done a rollout this extensive or invasive to our business since moving to XP 10 years ago. Let’s get ‘er done.

Now I must say our customers are pretty astute when approaching a project of this magnitude. But despite that, in just about every conversation I have there are always things that come out that weren’t considered. That’s why our customers love working with us – we’ve got the knowledge and expertise that they need to be successful and we make them look good.

For more information about Compugen’s Windows 7 Acceleration Services, check out the deck that my boss, Joe Addison, and I presented at a recent event. Let me know if you want to know more or are interested in one of our workshops or assessments.

Ruth's signature

One thought on “What not to do when deploying Windows 7

  1. Pingback: What not to do when deploying Windows 7 - Morton-ology - Life in a creative, technology-filled world

Leave a Reply

Your email address will not be published. Required fields are marked *