If you would like to read the other parts in this article series please go to:
- Windows 7 Compatibility Testing (Part 1)
- Windows 7 Compatibility Testing (Part 2)
- Windows 7 Compatibility Testing (Part 3)
- Windows 7 Compatibility Testing (Part 5)
- Windows 7 Compatibility Testing (Part 6)
- Windows 7 Compatibility Testing (Part 7)
- Windows 7 Compatibility Testing (Part 8)
In my previous article of this series, I explained that before you can even begin testing applications for compatibility with Windows 7, you must compile an inventory of the applications that are being used within your organization.
After you have compiled an application inventory, the next step in the process is to begin taking stock of the applications that are running within your organization. If you work in a highly managed environment, then you probably know exactly which applications are being run by which users. For everyone else though, you can realistically expect there to be some surprises and some ambiguity when you review the application inventory.
Some of the applications are going to be obvious to you. For example, if the IT department in your organization deploys Microsoft Office to every desktop, then you should expect to see Microsoft office listed among the applications that your users are running. Likewise, you will know going in that this is a widely used application that you are going to have to support after the upgrade to Windows 7.
Some of the other applications that are reported as being used may not be quite so obvious to you though. Several years ago for example, I decided to perform a software audit against the desktops in the organization that I was working at. I thought I knew exactly which applications were deployed to the desktops, but I wanted to perform a software audit any way so that I could ensure that I had a sufficient number of licenses for each application. To make a long story short, the inventory collection process revealed several unauthorized applications.
In that particular situation, it was pretty easy for me to spot the bootleg applications. After all, the office was fairly small, and I knew exactly which applications should have been installed on each PC. Even if I hadn't been intimately familiar with the authorization desktop configuration, some of the unauthorized applications were not exactly subtle. Titles such as 3-D Space Commando tend to stand out when placed on a list of business applications.
In the situation that I just described, finding out which applications were running and which applications were authorized to run was an easy job. The office was relatively small with only about 50 desktops, and I was the one who had made the decisions regarding which applications should be used. The situation was more of an exception than a rule though.
Earlier in my IT career I worked for a large insurance company. The building that I worked in had over 1000 desktops, which made application management a bit more challenging. Further complicating things is the fact that there were numerous individual departments, and each department worked nearly autonomously. As such, every department had their own set of applications that they used. As if that were not enough, some of the larger departments were subdivided into teams, and often times the applications would vary from one team to another even within a department.
As you can imagine, this IT free-for-all turned into a technical support nightmare. The organization's help desk would routinely receive calls asking for help on applications that they did not even know existed. Eventually though, the escalating support costs and inability to provide support on certain applications lead to an initiative to standardize the applications that were running within the organization. Although this happened many years ago, the standardization process that I worked through then is very similar to what you may encounter in preparation for deploying Windows 7, and many of the lessons that were learned are still relevant today.
One of the first things that the IT department did in preparation for standardizing applications was to compile an application inventory. In doing so, one of the first things that we discovered was that there was a great deal of inconsistency among software versions. For example, there were at least three different versions of Word Perfect being used throughout the building.
That being the case, one of my first initiatives was to ask everyone to run the same version of each application. I sent out a memo explaining that anyone who is running an older version of Word Perfect would be upgraded to the latest version. Unless you have dealt with this type of situation in your own organization, you would be absolutely amazed at the protests that my memo drew. Some departments were angry because they thought that they would have to pay for the new version. Others were upset because they did not want to have to commit the resources to train their users on the newer version of the software. Still other complaints came from those who simply liked the look and feel of the older version, or who had concerns about compatibility issues between the new version and some other piece of software that they were using.
The reason why I am telling you this is because in preparation for an upgrade to Windows 7, you will likely find some older applications that will have to be upgraded in order to run optimally in a Windows 7 environment. My experience has been that generally speaking, people are resistant to change. Sometimes mandating a version upgrade may be met with a degree of confusion or hostility from management. As such, it is important to have a compelling argument in place before you announce the upgrade.
Another thing that I found in my effort to standardize applications was that some departments used different applications to perform the same task. At the time, Word Perfect was the word processor of choice for most of the organization. However, some departments chose to use Microsoft Word instead. There were also a few people who used now extinct applications such as PFS Write or Word Star.
Being that my goal was to standardize the applications that were being run in an effort to reduce support costs, I had to make some difficult decisions regarding which applications would become the new standard for the organization, and which applications would be phased out.
When it comes to reviewing the application inventory prior to Windows 7 compatibility testing, you may also discover that there are multiple applications within your organization that are being used for a common purpose. You do not necessarily have to eliminate all but one of those applications the way that I did. After all, I will be the first to admit that forcing users to adopt a different application from what they are used to ruffles a few feathers, and greatly increases the volume of calls to the help desk (at least until everyone gets used to the new application).
Even if you do not plan to standardize your applications, it is important to at least make note of applications that can be used to accomplish a common task. Later, when it comes time to perform compatibility testing you may find that there are applications that simply do not work correctly with Windows 7. If there are alternative applications that are already being used in your organization that are capable of performing the same tasks as the incompatible applications, then those applications may prove to be a viable alternative to the application that does not work correctly with Windows 7.
In this article, I have explained some of the issues that you may run into as you review the application inventory that you have collected from the workstations in your organization. In Part Five, I will continue the discussion by showing you some more things to look for as you review the inventory that you have collected.
If you would like to read the other parts in this article series please go to: