Jay Butler, Senior Technical Consultant

Jimmy has been a conscientious Systems Administrator for the past several years now, during a booming era of technology advancement for community financial institutions like his own. He derives worth from his position by encouraging, accepting, and making changes to the network and believes his superiors greatly value this propensity. He works diligently to ensure software is up-to-date with the latest available versions. He has rightly gained confidence over the years and takes initiative to make changes on his own. Jimmy is driven by a righteous intent that motivates him to get things done. This is a great quality, but to be a truly valuable asset to the business, it must be properly directed because with change comes cost.

Jimmy is part of an entrenched psyche that says unrelenting change is required when it comes to technology, a psyche that sometimes overshadows common sense. It is easier to just go along, and after all, strenuous change is just part of the job. There is new software, new regulatory requirements, faster, better, “cool” all the time. During economic booms changes come quickly when the cost is not closely scrutinized. Now with the economy in an obvious slow down, carefully allocating precious resources is more critical than ever before. Be sure changes are necessary before proceeding regardless of how low the cost may appear because there are usually additional hidden costs that can be exorbitant.

Making even a small change can result in unintended consequences particularly when it involves the infrastructure. For example, the well intended Jimmy understandably likes to tinker and do things himself to show his value by making improvements, so he decides to implement File Synchronization for all users with a new Group Policy. He explains to his superiors how this will allow users to access their documents without access to the home drive such as when a laptop is off the network or during a server outage. Jimmy also explains how this change will help protect anything stored in My Documents by copying it up to the server. Users and management are excited to hear about the new features, so he fully proceeds with the implementation. He soon realizes Folder Redirection will also be required to protect My Documents the way he described. With this revelation, the project has suddenly become more complex, but Jimmy presses on. When he begins to create the new Group Policy he comes to realize that bringing this into production is going to be a major undertaking beyond his original calculation. At this point, he certainly does not want to tell the users he has changed his mind. Because Jimmy has experience and technical prowess, he eventually strikes on the right formula and gets it working. Only, he has spent far more time than intended and introduced added complexity that soon creates unforeseen consequences.

Shortly after implementation, Jimmy begins to get calls from users having problems with the synchronization. He had overlooked user training requirements and he did not perform adequate testing ahead of time. Over the next month, Jimmy has to “put out fires” all over the place because he had no way of knowing all the pitfalls that would arise from something that at first seemed very simple. He finds himself in an awkward, stressful situation that has somewhat damaged his reputation even though he is working in overdrive. Other duties suffer while Jimmy struggles to keep up. What should he have done differently?

Before deciding to make any change to the system, an effective change management process requires a thorough analysis of why the change is being implemented, and what the intended result will be. A risk assessment of the change will determine what the impact is to the Bank if the change is not implemented or has an unintended result. In addition, all system changes should be tested in a non-production environment prior to roll-out. The first question should always be”Why are we doing this” and that answer should be clear and in vivid detail, even to Jimmy who is not always involved in the decision for change. By clearly understanding the precise reason behind a change, Jimmy may have the opportunity to introduce a less risky, more cost effective, solution. In his own case, Jimmy should have analyzed the question a little more and he would have realized File Synchronization for everyone was unnecessary. Only a few users really needed it, and he could have configured and trained them individually rather than make an infrastructure change. He could have used a more simple Folder Redirection policy for everyone to assure the protection of My Documents on the server. Even then, extensive testing should be performed prior to deployment and administrative overhead must be an acknowledged cost up front. Then there is the question of security with Folder Synchronization because it instigates an automated means of propagating business data beyond the network boundary.

Most costly computer problems are caused by well intended changes like this one. “What changed” should be the first question asked at the start of any technical support event. Sometimes the change is apparent in the case with Jimmy. Other times the change was made months back and is never determined as the cause. In either case, the point is to control change as much as possible. Always begin with the question as to why the change is necessary. After understanding and concluding change is unavoidable, determine the possible solutions and the associated risks of each to help evaluate hidden cost. Check with your network provider and other sources to determine the best course of action. A support provider has the luxury of interacting with hundreds of financial institutions like yours and likely has some insight. Once the best solution has been concluded, the next phase involves testing. Try and perform the changes on a limited basis at first or in a lab environment if possible. Perform the change in small increments and over time to prove the viability of each change made. Making many changes at once significantly increases the difficultly of solving any problems that arise. If multiple vendors are involved be sure to know the responsibility of each and when possible allow only one vendor to make changes at a time.

Be sure to note any change no matter how slight it may seem and contact your network provider for insight ahead of time. People or parties not responsible for the overall support of your network should not be allowed to make changes exclusively. If you cannot determine a solid reason for a change, do not make it. If your risk assessment determines the change is too risky right now and not absolutely required, it may be smarter to wait for a more refined solution. Keep your positive intention flowing, but temper it with a strong sense of caution when it comes to making any network changes.

Write a Comment