In spite of its many benefits, switching all of the users in the company from a client / server deployment to a thin client deployment is a big undertaking. There are a lot of things that can go horribly wrong that you may never even know about until after the roll out is complete. A classic example of this is that some applications simply refuse to work in a thin client environment. Another possibility is that your server may not be up to the job of handling the workload that it is being given. The point is that it would be extremely foolish to take a network that is working perfectly and convert it all over to a thin client environment without doing some testing first.
Test Group Selection
One of the most crucial tasks in a pilot deployment is figuring out which users to include in the testing. This is actually a much more difficult task than it might at first sound. The reason is because you have to be able to run the test with enough users that you can be sure that the test group’s experience will be an accurate reflection of what will happen when everyone else eventually gets converted over. At the same time though, you have to assume that there will be problems during the testing phase. Therefore, you don’t want to involve any users whose jobs are critical to the company’s ability to conduct business. Likewise, you will have to avoid running the tests on any combination of users who would have a serious negative impact on the company’s image or on the company’s ability to conduct business should a failure occur.
There are generally two schools of thought when it comes to selecting users for a pilot deployment. One popular technique involves selecting one of the company’s less important departments and running the tests on that department. The other test involves choosing a bunch of random employee names and then eliminating the names of employees with critical job responsibilities and then performing the tests on the names remaining on the list.
I tend to prefer the random sampling method for a couple of reasons. For starters, I don’t like the idea of running an early pilot deployment against an entire department because of the chances that something could go horribly wrong. OK, I know that most of you that are reading this are probably smart enough not to go and pick the payroll department for your pilot deployment, because you want to make sure that you get paid on Friday. At the same time though, unless you count a particular insurance company that I used to work for, most companies do not have unimportant departments. Sure, maybe the marketing department seems unimportant, but what happens if your deployment is flawed, and the entire marketing department were to experience a catastrophic failure? You would eventually fix the problem, but in the meantime the company isn’t attracting any new business and may not be able to respond to inquiries from potential customers. This could effect your company’s bottom line in a way that eventually results in financial cuts being made, and nobody wants that.
The other reason why I don’t like using a single department for a pilot test is because doing so does not give you an accurate sampling of the applications that are being used throughout the company. Let’s pick on the marketing department again. In the last company that I worked at, the marketing department employees used Microsoft Outlook, Power Point, and Publisher, and that was about it as far as applications were concerned. If you only ran the pilot deployment against the marketing department, then at the end of the testing cycle, you will have no idea how the transition to a thin client environment will effect the guy in the finance department who is running Quick Books. Running a pilot deployment against a random sampling of users insures that you will be able to test a wide variety of applications.
Train the Support Staff
Once you have chosen which users will participate in the pilot deployment, then the next thing that I recommend doing is training the support staff (before you even begin the deployment). Even if it is nothing serious, I can almost guarantee you that there will be some issues that come up. Your support staff need to have training so that they know how to respond to those issues.
I once worked in an organization in which the majority of the management personnel in the IT department had a sort of messiah complex. They were known for testing new applications and not even telling the help desk staff. When things went wrong, the help desk staff would just start getting calls about things that they didn’t even know existed and were expected to be able to fix the problem. Don’t even think about testing a thin client deployment on users without telling your help desk staff first. You need to decide up front who is going to support the thin client pilot deployment and make sure that the support team receives adequate training.
While I am on the subject of training, I want to point out that the support staff are not the only ones who need to be trained in regards to the thin client environment. You should also insure that the Administrative staff also has adequate training. The administrative staff needs to know how to deploy and manage the thin client environment. Likewise, they need to know enough that they can accurately measure the impact that the pilot deployment is having on the terminal server and on the network as a whole. They then need to be able to take that information and use it to forecast the impact that can be expected when the whole company is eventually converted over.
Train the Users
It might seem a little weird to say this, but you also need to make sure that you have a plan in place to train the users who will be participating in the pilot deployment. The training doesn’t have to be anything fancy. At a minimum though, you should instruct the users in how they will be logging into the thin client environment. You should also make sure that the users know who to call if they should have a problem and let the users know exactly what they should expect from the support staff. If you think that it could take a full day to sort some problems out, then be honest with the users and tell them that. It will help to prevent tense situations later.
Have an Abort Plan
The last thing that I want to mention is that you need to have an abort plan in place. It could be that after you deploy the thin client environment to your test users that you find that some critical application is incompatible with the new environment and that no amount of tweaking is going to make it work. If that is the case, then you need to accept that there may come a point when you need to just cut your losses and revert to the old system. If that point comes, then you will need to have a plan in place for switching everyone back to their previous environment as quickly and efficiently as possible.
Conclusion
As you can see, there is a lot of testing that should happen before switching from a client / server deployment to a thin client deployment. In this article, I have discussed some issues that you should consider when planning for the initial testing.
