As I sit down in New York’s Grand Central station to write this, my first “Confessions of a Sysadmin” editorial for Simple-Talk, with people coming and going all around me, it feels only natural to tackle the topic of change, and how to manage it. Each of us has to manage change to some degree, in our working and personal lives, but I’d be willing to bet that whoever said that “change is the only thing that ever stays the same” probably worked in IT.

As a systems administrator, welcome change or shun it, change will happen. It is inevitable, constant, and unyielding. Failing to learn how to use change to your advantage would be foolish and dangerous; your competitors are surely going to. However, in order to benefit from change you need to know how to manage it effectively, and I’d like to review some of the key points and skills that will help you accomplish this goal.

Usually, the spur for change is the recognition that a problem exists in a process, followed by a “grand vision” for a better way to do it. Sounds easy, right? It isn’t. I’ll show you precisely how difficult it can be as we go through the steps of a successful change.

Early last year, the president of our company came to me with the news that our corporate headquarters was relocating from downtown Manhattan to central New Jersey. We’d also be opening an  office in mid-town to keep a presence in New York City, and I was responsible for ensuring that there would be no interruption in IT services before, during, and after the move. Let’s see how I handled it and where I could have improved.

Overcoming the Status Quo

Regardless of how great your idea is, you will encounter resistance. People in every organization are attached to the status quo, and will often resist your vision for change. Many are afraid of change in and of itself, others are afraid of losing their control over a system, and some find no profit from changing a system that, in their opinion, “works fine”.

You need to create a sense of urgency around the problem, and the need to fix it, but at the same time it is incredibly important that the opinion of each member of the team is heard. If a person is resistant to your ideas, you need to do your best to find the root of their concerns and then assuage their fears. In my experience, sharing feedback and input from the whole team often helps people feel more comfortable with the change. Ideally, every member of the team should subscribe to your vision, although you will inevitably encounter members who consistently disagree with the consensus. Every voice should be heard, but you can’t let a vocal minority tie the hands of the entire team. Examine the objection to see if it has merit, and if none exists, move on.

It goes without saying that “buy in” from the people with the power is vitally important to your success. A formal proposal may need to be created and presented to management to begin the process. While it is outside the scope of this article, tutorials on writing business proposals can be found through your search engine, and once it’s written, have others read and revise it for clarity.

In my case, the change was a mandate handed down from above. Rent prices in downtown Manhattan were increasing, and our growing company needed more room. Aside from the interpersonal issues involved with dividing an office, resources were finite.  Employees were concerned that their new office wouldn’t be equivalent to the previous one, or that they wouldn’t be able to perform their tasks as well as they were used to.

I knew that the success of the move would judged in part by how comfortable everyone would be in their new locations, so I took that into account while explaining the various changes to the employees.  What I didn’t do enough was listen. I talked “to” (and at) people more than “with” them. Had there been more discussion, I believe everyone would have felt more like they were a part of the decision making process, which goes a long way toward accepting the transition.

Research: Mapping your Path

You now have a documented goal, and a team who share your vision. You must now analyze the goal, and carefully map your route from where you are not to your destination. Try to anticipate the roadblocks you will face. Thorough research is vital: you will often find that others have tackled the same problem before you, and you should learn from them. Internet forums, for example, are a great resource of knowledge and experience.

It is vital to have a central repository for the information you gather during the research process, to which every member of the team has access and can contribute. Some form of web based wiki would make an ideal resource, although many network-based project management solutions have this sort of thing built in.

As you start amassing information, ideas will emerge for how to put together a solution which meets the requirements of the goal. Hold regular group meetings and start to carve out a rough sketch of the solution’s design.

I planned many aspects of the move, worked with vendors and contractors, managed quotes, and so on, but I personally don’t feel like I communicated with management enough during this process. There must have been some amount of trust, as they didn’t ask me about much beyond the occasional status update, and I was far too busy to volunteer information. If this were a complex project involving several other people, lack of communication would have sunk me.

Also, because I was the only member of my team, instead of a centralized repository on the network, I used a notebook. At the time I thought it was sufficient, but now I’d like to go back and see what I did, and of course I’ve misplaced the notebook among a stack of others.

Design and Scheduling

It is very common to go back and forward between the design and research stages, to the point that they may seem to blend together. Be careful not to lose momentum here. Revisions are inevitable, but progress is necessary.

As your ideas evolve and become more detailed, you’ll find it useful to segment the goal, so that team members can specialize on specific areas. It makes the whole project more manageable, and having members work exclusively on a specific section increases their efficiency because they begin to “own” that part of the solution, and have an investment in its completion. Make sure that the smaller team reports regularly back to the main group. As the team leader, it becomes your role to ensure that they are making progress.

Certain sections of the task will likely depend on others that need to be completed first. Until you know what you’re up against it will be very difficult to generate a schedule. Arrange the tasks in order of necessary completion, and have every team weigh in on the time their particular task is likely to take (all of this should be recorded in your central repository). This forms the basis of your development time schedule. Remember, however, that this is your ideal time. It would be wise to remember Hofstadter’s Law:

“It always takes longer than you expect, even when you take into account Hofstadter’s Law“.

Documentation of requirements should be produced for each smaller team in order to verify satisfactory completion at a later date.

Always remember to schedule in sufficient time for thorough testing. Many people find that adding one third of the estimate tends to be relatively accurate.

Thought should also be given to the eventual support of the solution which is to be implemented. Does documentation need to be produced, does there need to be a new team created to handle this support? These are things that will need to be examined and decided upon as early in the process as possible.

My design phase went relatively smoothly. The hardest parts for me were keeping up with changes to the spaces we were moving into, and timing the various vendor/contractor interactions. Scheduling circuit installations around wiring-completion dates and phone-vendor delivery dates was difficult, and if I didn’t have it all planned out ahead of time, it would have been a disaster.

What I did wrong was to misjudge the amount of network bandwidth necessary for the office to function correctly. I vastly underestimated when I should have relied on graphs. Had I done that, a last minute rush to order dedicated circuits wouldn’t have been necessary, and people’s initial impressions would have been much better. Rely on facts rather than hunches.

Development

Once the specifics of your design start to emerge, you’ll need to begin development in order to keep your schedule. It’s easy to become myopic during the development of the solution, particularly when working on a small segment of a much larger design. Through regular meetings, keep the teams aware of each others’ status, and keep your individual groups moving towards the original vision and design.

On occasion you will, either through short-sightedness or lack of accurate information, discover that the design which was carefully developed is incompatible with the real world. You may need to fall back into design on a specific task or, if you are particularly unlucky, it may involve several smaller units. Bring together the involved teams and the original design team and work together for a solution.  When solutions are updated, remember to update the requirements and user documentation which was produced beforehand.

As your teams approach completion of their specific tasks, care must be taken to ensure that every item is met satisfactorily, according to the agreed specifications. Only in this way can you be sure that the solution will effectively solve the stated problems and create a positive change. As the team leader, sign off when the team completes the requirements placed on them, and reminders may be required if they are neglecting one or more tasks.

It should go without saying, but every major change needs to be built in an environment that is segregated from the “real world”, otherwise the usability of whatever you are improving will be at the mercy of your design and development processes. Build a complete solution and use it to replace the status quo, don’t destroy the status quo while you build the solution, or you will have a vacuum in the interim and a lot of miserable people.

When you have a solution that satisfies your requirements, you need to create a schedule for replacing the existing system that will not create undue outages or break functionality. My advice is to work with your team to practice putting the change in place, then use that practice to calculate the required time, and multiply that by one third, as discussed previously.

For my migration,  IT resources were required to be in place prior to the physical move. This required thorough testing of network ports, telephone access, and the like.  As the spaces were independent of our inhabited office, there was sufficient time to test these resources. In a more time-sensitive operation, more manpower would have been needed.

Training and Support

After rolling out the change, you must provide support to the people affected. Providing them with documentation and personal assistance is well worth your time. People resent being left in the cold, and your change will be received poorly if they feel deserted or misused.

A group training session may be necessary and presentations should be delivered by a member of your team who understands the change and its consequences, and they should be prepared to answer pertinent questions. The goal is to make people feel at ease and comfortable with the change, and to reassure them that help will be available if they need it.

As we didn’t have the resources to purchase matching phone hardware, normal business telephone lines were installed in one of the locations. This caused some confusion for personnel at that site, because I didn’t anticipate the need to train them on these phones. To remedy this, I drafted and made available documents describing how to perform various functions using the available hardware, and reached out personally to the users to help them become accustomed to their new phones. I think that they appreciated the response, and we have had no further problems since then.

Project Evaluation

After a suitable length of time, it is advisable to evaluate the performance of the team and its leaders. Future performance can be improved by examining the mistakes that were made, correcting them and developing better strategy for next time. Review each team member’s performance, and offer praise for appropriate conduct, or constructive criticism if it could have been improved. Be fair and honest, and the team members will respect you for it, even if they aren’t happy with everything that you have to say.

We’ve been in the new offices for several months now, and things are going very well. Management follow-up on the move has been positive, and my users seem content in their new locations. Initial problems could have been resolved more quickly or eliminated altogether had I relied on statistics for bandwidth requirements rather than guessing, but overall the transition was smooth. I received kudos from our president for making the migration happen as well as it did, and I’ve now got several more upcoming changes to manage. 

Summary

How can anything so simple be so complex? Change is more than just moving from one state to another. It is an ideology, a force of nature, and a tool for improvement. Change is the ability to alter the world around you. You are not powerless in your life, or in your work, despite what other people may tell you. Put change to work for you and reap the benefits. Form your goals, develop your plan, and implement the changes.