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 4)
- Windows 7 Compatibility Testing (Part 6)
- Windows 7 Compatibility Testing (Part 7)
- Windows 7 Compatibility Testing (Part 8)
In my previous article, I began talking about how you can use the application inventory that you have collected as a mechanism for helping you to standardize the applications that are in use throughout the organization. In this article, I want to continue the discussion by talking about the importance of prioritizing the applications that are reported within your inventory.
As you work your way through the list of applications that you have collected, you will almost certainly discover that some of the applications that are being used in the organization are more important than others. As you perform your Windows 7 compatibility testing, you will likely discover that some applications simply do not work correctly with Windows 7. In these cases, it is essential to know how important the application is to the organization.
Believe it or not, prioritizing your applications is more difficult than it sounds. This is primarily due to the fact that the IT department may not have a firm grasp on how employees in other departments do their day-to-day work. For instance, you may know which applications are being used by the finance department. You might also have a general idea of the types of tasks that the finance department performs. However, it may be unclear as to which applications are used to perform each task. The finance department employees might also perform some tasks that you do not know about.
This being the case, prioritizing applications usually involves much more than simply going through the application inventory and deciding that one application is important while another is not. In almost every situation, you will need to meet with department managers or supervisors and discuss how important each application is to the department.
As you do, do not be too quick to write off unused applications. I once had a situation in which I was meeting with individual department heads to discuss which applications were still being actively used. As I went through the application inventory with one of the departments, they informed me that a particular application had not been used in years. I saw this is a golden opportunity to reclaim some server resources. Thankfully, I had another meeting that afternoon with a manager from another department. What I did not realize was that this other department used the application that I was about to remove on almost a daily basis. My point is that as you meet with the various departments, it is imperative that you reserve judgment until after you have met with everyone.
Once you have met with everyone and gotten a sense of how frequently each application is used, you will have to go back and make some decisions regarding the importance of each application. Keep in mind that application importance isn't always a black-and-white issue. For example, you may find that there is an application that is used on a semi regular basis, but that you cannot classify as being mission-critical. What do you do if you find out that this application is not compatible with Windows 7? Do you give up on the entire upgrade process? Do you get rid of the application? The answer probably depends on how important you deem the application to be. This is why the classification process is so important.
As you have seen, simply classifying applications as important or not important doesn't always work. With that in mind, I recommend using several different levels of importance when classifying applications.
The least important applications in your organization are those that you determined to be irrelevant. As time goes on, a business's needs change. As an organization evolves, applications that were once considered critical may eventually become completely irrelevant.
A classic example of such an application is an OCR package that one of my clients used to use. Back in the 90s, this particular organization invested huge amounts of money and OCR software that was used to process hand written forms. Today though, the organization doesn't even use paper forms. Instead, customers file claims on line through a Web application. As such, the once mission-critical OCR package is now completely irrelevant to the company's business model.
Sometimes, you may find that even if an application hasn't become completely irrelevant, it really isn't very important to the organization. These types of applications can best be classified as Optional.
Optional applications are those that are seldom used, and that do not directly impact the company's bottom line. Suppose for example that an organization uses a desktop publishing application to create the company's monthly newsletter. Obviously, the person who is in charge of creating the newsletter would probably like to be able to continue using the desktop publishing application. However, if the application turns out not to be compatible with Windows 7, you probably would not abort the entire, company-wide upgrade because of this one application. After all, an internal newsletter probably has nothing to do with the organization's core business functions. Besides that, it would be relatively easy to find a similar application that does work with Windows 7.
Most of the applications that are in use within your organization are probably important to at least someone. As you begin classifying the applications that show up in your software inventory, you may have to establish multiple levels of importance.
If your company has already established Service Level Agreements (SLAs) on a per application basis, then determining an application’s true importance is probably going to be easy. All you have to do is look at the SLA to find out how valuable the application really is to the company. If SLA's have not been assigned on a per application basis, then you will have to make some decisions as to just how critical each application really is. Fortunately, there are some clues that can really help you out.
I recommend classifying important applications as Important, High Priority, and Mission Critical. So how do you distinguish between these prioritizations? In my opinion, the best way to derive an applications true importance is to consider the fallout that would occur if the application were to fail.
For example, if a mission-critical application were to fail, it would not only directly impact the organization's bottom line, but you can be sure that someone's cell phone would be ringing within a matter of minutes.
In contrast, a high priority application is probably going to be considered critical for a single department, but may not be critical to the organization as a whole. In other words, one department would probably be seriously hindered by the failure of the application. However, the organization as a whole would still be able to do business (although not in an optimal manner) while the application is being repaired.
An important application is something that is used on a regular basis, but that wouldn't necessarily cause huge problems in the event of a failure. For instance, I use dictation software to write most of my articles. To me the dictation software is an important application. However, if it failed I could always type my articles for a few days until I get the dictation software fixed.
Classifying applications is the last step before you actually begin the compatibility testing process. In the next article, I will begin showing you some techniques that you can use to determine how well each application will work after an upgrade to Windows 7.
If you would like to read the other parts in this article series please go to: