CHAPTER 4. Upgrading Strategies and Project Management

SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE

---

Where Do You Start? 42

Determining When an Upgrade Is Necessary—The Evaluation Process 43

What Resources Are Needed for the Upgrade? 48

Planning an Upgrade 49

Testing the Plan 51

Deployment 53

User Training 54

Closing the Book—Documenting What Has Changed and Why 54

Other Considerations for Upgrading 54

This chapter discusses some things you should consider when deciding whether an upgrade is needed for the network, and some of the steps necessary to accomplish the task. It is not a simple task to undertake a major network upgrade. It is not a simple task to undertake an upgrade of even a single departmental network, depending on the applications, servers, network bandwidth required, and other factors. Any sort of upgrade contemplated in this book should be done so in an orderly fashion, and the appropriate documentation (before and after) needs to be created. Documentation does not mean that you have an absolute set of directions that must be followed. Instead, it is a set of documents you can create before the upgrade, and then modify as circumstances reveal new problems or opportunities that may arise during the upgrading process.

Where Do You Start?

You have to start somewhere, and sometimes it’s best to keep the process fairly simple. Consider the following steps:

1. Determine the need for an upgrade.

2. Set goals.

3. Create a plan to guide the process.

4. Carefully investigate the plan to help ensure success.

This may seem too simplistic at first glance, but stop and think: Why are you performing an upgrade? Is it because you just read about the newest technology and your budget lets you buy it? Or does the new technology solve a network problem related to your business? After you have determined a real need to make an upgrade to all or (more likely) part of your network, you need to justify these changes to management (to get the funding) and make sure that you set goals that satisfy the needs of your network clients. It doesn’t mean anything if you spend a half-million dollars (or more) installing the latest Storage Area Network (SAN) if your clients don’t notice some improvement in performance or uptime.

However, if your hardware is old, you are likely to find that the vendor will continue to raise support costs to maintain this equipment. In that case, an upgrade can be justified by the cost of maintaining the older hardware, as well as the possibility that replacement parts may not be available in a few years. Because a major upgrade can sometimes take a year or more, you might consider an upgrade before you are forced to do so by your hardware vendor. Another thing to consider is whether there is an actual need to upgrade. For example, implementing a SAN might solve many problems, such as centralizing storage management on the network as well as providing additional capacity. SANs also can be created in such a way that you can incrementally add storage on an as-needed basis.

The next part of this chapter enables you to create goals for a network upgrade, as summarized in the following list:

Evaluation—Understanding the current environment. You can obtain this from your current resources and feedback from users.

Determining needs—Why are you upgrading? As stated previously, do you really need the upgrade? If it doesn’t solve a problem for your network, you may find yourself simply spending money because it is available. Yet if you have the foresight to see that the upgrade will fulfill a future requirement (such as pulling fiber-optic cables to replace copper cables), then you might justify the cost based on future, more expensive labor costs.

Setting goals—What will the upgrade accomplish? Will you improve the user’s perspective of the network? Will you provide additional services (think of certificate services and security) that will benefit the corporation as a whole?

Budgeting—Determining what financial resources are available and setting a budget. Despite the fact that most administrators fail to understand budgeting, this is a basic premise of running a company. If you can’t afford it, you can’t afford it! Sometimes you just have to make do with older technology and plan the upgrade for the future. Some networks still use Windows 98 or Windows NT, and have a migration to Windows XP/Vista or Windows Server 2003 on hold into their future.

Planning—Creating a detailed plan for the upgrade. This is where you will make or break your argument with upper management. If you cannot show them why an upgrade will benefit the company—based on costs of maintaining the network to user productivity—then they have no reason to approve your project.

Testing—Evaluating components of the upgrade in a laboratory or pilot project environment. This is emphasized in many other books for good reason. It’s crucial to put the plan to the test and prove that a plan is feasible and appropriate. For example, Microsoft’s Resource Kits usually contain information on deployment and planning, which can be very helpful to you if you are rolling out an upgrade in an enterprise network.

Training—Will users need to be trained on any new applications or features? Training is one of the more expensive items for any new network upgrade. Even if you are planning an application upgrade, rather than a network operating system upgrade, user training is a necessity if you want users to know how to use the new features that come with the upgrade.

Backing out and recovering—Coping with the unexpected. No matter how well you plan, something can always go awry. And when it does, your job may be on the line if you can’t restore the network to its previous state. Upper management doesn’t care as much about perceived new benefits from newer network technology as they do about keeping the business humming along.

Deployment—Implementing the upgrade plan. This involves a team of technicians, each of whom is an expert in the technology that is their responsibility in the upgrade plan. Just because you are the network administrator (or manager of such) doesn’t mean that you should rely on your own knowledge to micro-manage every aspect of the project. You should instead concentrate on managing the individuals whose job it is to get things done.

Post-implementation review—Did the plan work as expected? Are the results what were expected, possibly more? There is nothing more satisfying than presenting to upper management a document (whether they read it or not) detailing how your upgrade plan worked, and the benefits that have now been accomplished. This helps you keep your job!

Determining When an Upgrade Is Necessary—The Evaluation Process

A data network in a business is much like a nervous system in a living organism. Usually, when the business grows, the network also must grow to keep up with new users and newer functions. When a business suffers and shrinks, the costs associated with a larger network must be re-evaluated to determine whether they are still feasible under a smaller business organization. A network rarely goes unchanged year after year.

Before you begin to write an upgrade plan for part or all of a network, you first must determine that there is a need for an upgrade. There are several reasons to upgrade a network:

User complaints—When top-performing users complain, their managers usually do their best to make them happy. Keep in mind also that there are always going to be people who complain about the network. Investigate user complaints to determine whether they are valid.

New technology has been adopted—Sometimes the upgrade can be application driven. A new kind of hardware or software needed by a business unit demands a network with higher performance capabilities or different features.

Business mergers and expansions—After figuring out a way to join two networks when companies merge, a long-range plan must be developed to make the network work best for the new business entity. This can include performance enhancements, adoption of standards, and elimination of duplicated components. This also can result in a major headache if you have to find a way to combine user authorization data from different operating systems.

The history of business mergers is littered with example after example of companies that fail to adequately plan for the information technology aspects of a merger. The Penn Central debacle of 1970 and the slowdowns across the West and Southwest after the Union Pacific takeover of Southern Pacific in 1996 are just two examples. Failing to plan for post-merger networking issues is, in reality, planning to fail.

Business is good; let’s spend money—This is not an uncommon motive for making a new system or network purchase. Sometimes when economic times are good for a business it’s also a good time to make long-range plans and upgrade part of the infrastructure. Yet, as stated previously, don’t spend the money on just the latest, greatest technology. Consider this a windfall and evaluate the network components that can benefit from this additional cash. Do you have a need to provide mobile users with wireless capabilities? Do you need to upgrade your firewall capabilities to ensure the security of your network? Don’t waste money when it is available. Think of the long term.

The first of these reasons, user complaints, probably will never go away. No matter how fast the network or how powerful the machine, there will always be someone who wants more. Usually a network administrator has a good overview of the people or departments that are major consumers of network resources and can filter out unrealistic complaints. So when deciding when and whether you need to perform some kind of overhauling of the network, you should carefully research your current network’s capacity and compare it to the business needs currently loading the network.

Sometimes a simple overview of the network can reveal that all you must do to satisfy one or two small bottlenecks is reconfigure part of the network. Usually a reconfiguration is cheaper and easier to implement than a major upgrade. It’s much easier to upgrade a single, growing department to a faster switch than it is to overhaul the entire network.

When reconfiguring the network will not solve capacity problems, it might be time to look at other media to handle the network traffic. Chapter 6, “Wiring the Network—Cables, Connectors, Concentrators, and Other Network Components,” gives a good overview of the specifications and capabilities of this most basic part of the network. Whether you are planning an upgrade or simply extending your network into a larger geographic space, it’s not necessarily a good idea to shop around and settle for the cheapest solution. Installing cabling in ceilings, walls, and floors is a labor-intensive, expensive item in an upgrade budget. Yet if you spend the money up front to install good-quality cables, connectors, and the like, you will probably quickly recoup the cost in a few years when upgrading to even faster networking technologies. For example, you can use Category 5, 5e or 6 for a 10/100 Ethernet network. Any of these cable types can also support Gigabit Ethernet. However, Category 6 cable can support faster transmission speeds and provide greater signal quality, making it a good candidate for even faster network standards. If you want to make a long-term investment in your UTP cable plant, use Category 6 rather than Category 5 or 5e.

There are other chapters you might want to consult when planning an upgrade. Chapter 7, “Network Interface Cards,” covers the basics of this topic. You also can find information there about some of the more recent functionality that has been incorporated into NICs, such as Wake on LAN and server NIC load balancing. After you have the wiring and NIC issues settled, Chapter 8, “Network Switches,” guides you through the process of replacing overloaded department hubs with switches to improve performance and connect dissimilar LAN segments. If your network still implements generic hubs one of the first upgrades you should consider is replacing them with switches. Ethernet hubs are now legacy equipment. If you are considering wireless Ethernet, see Chapters 18–23 for information about technologies, speeds, and security features.

Adopting new technology usually entails additional tasks such as training users and administrative personnel in the use or management of new products. For example, a major paradigm shift, such as migrating an all-Novell network to Windows XP/Vista clients and Windows Server 2003 servers, would have to include months of training for network administrative personnel. For all practical purposes, TCP/IP is now the de facto networking standard for LANs. If you are still running an AppleTalk or IPX/SPX network, you might want to think about future support for these products. Novell already offers TCP/IP support, and there are products that allow interaction between Novell Directory Services (NDS) and Windows Active Directory. Although NDS still might be a useful tool, IPX/SPX LANs are good candidates for upgrading to TCP/IP, especially if your business connects to the Internet.

Another technology that might be ready for a change is the Token-Ring LAN. Although Token-Ring technology is a great LAN solution, the fastest Token-Ring adapters run at 100Mbps, and most run at 4 or 16Mbps. These speeds are outstripped by full-duplex Fast Ethernet (200Mbps effective speed) and Gigabit Ethernet. And when it comes to the budget, the number of manufacturers of Ethernet equipment dwarfs those who make Token-Ring hardware. Because of the economics of scale, and competition, Ethernet is a far cheaper solution in virtually every case. You probably won’t even need an adapter for your clients: 10/100 (and sometimes Gigabit) Ethernet adapters are built into almost all recent PCs.

For newcomers, Chapter 13, “Ethernet: The Universal Standard,” and Chapter 24, “Overview of the TCP/IP Protocol Suite,” will get you started on the planning process. Other chapters can fill in the details of some aspects typical of TCP/IP-based networks. For example, Chapter 25, “Basic TCP/IP Services and Applications,” will help you determine which of the basic TCP/IP-based applications will be useful in your network. Chapter 28, “BOOTP and Dynamic Host Configuration Protocol (DHCP),” and Chapter 29, “Network Name Resolution,” cover the basics of automating network addressing and name resolution.

Finally, one “upgrade” that every network administrator should plan for, if it has not happened yet, is to provide a firewall between the company network and any outside network connection. Chapter 45, “Firewalls,” covers this area. The chapters immediately preceding cover other aspects of network and systems security.

Today a firewall is not a luxury. It is a necessity. It doesn’t matter if you are connecting different LAN segments within a company intranet, or if you are making a connection to the Internet. A good firewall is now something you cannot ignore. Even SOHO users should use some type of firewall to protect themselves from the malicious problems that can result from a wide area connection. For a corporate connection to the Internet, a good firewall, no matter what the cost, is an absolute necessity. And in some professions, such as the pharmaceutical industry, or for those corporations that do business with the government, it is required. Most SOHO users will receive adequate protection from a software firewall (such as the firewall integrated into Windows XP Service Pack 2 or third-party products such as Zone Alarm), but corporate servers and networks need hardware firewall appliances for better protection. Both types of firewalls are discussed in Chapter 45.

Determining User Requirements and Expectations

One of the simplest methods of finding out what is needed on the network is to ask the users. Although this technique might not give you the most accurate results, it will at least give you an idea of what the user community expects from the network. Conducting a simple written survey can bring light to factors that administrative and support personnel might not be aware of.

Similar to surveying end users is soliciting suggestions from support staff who encounter user problems daily. Logs of support calls can be a valuable source of information. If users are making the same mistakes over and over again, then training, not upgrading, usually can solve the problem. When examining help-desk logs, don’t limit your scope to the problems. Carefully examine what was done to solve the problems. Maybe your help-desk personnel aren’t giving out the best advice.

However, the most basic way to determine overall capacity needs is to establish baseline data for your network components and then make comparisons on a regular basis with the production network. By keeping data that reflects the baseline mode of operation, you will have empirical data that can be used to make projections about future use. By regularly benchmarking your systems and keeping track of the data, you also can become aware of capacity problems that begin to creep up before your projections or expectations. Most operating systems provide for monitoring of a sort. Windows 2000 Performance Monitor, or Windows 2003/XP’s System Monitor, for example, can give you very detailed statistics on a server’s performance, including network performance. Chapter 5, “Protecting the Network: Preventative Maintenance Techniques,” gives an overview of this tool. In larger networks, using a management console that understands SNMP and RMON can help you baseline and monitor many different components in the network. Analysis software can help prepare reports that can be used to justify network changes. Both SNMP and RMON are examined in Chapter 49, “Network Testing and Analysis Tools.”

Other factors that can be reviewed to determine whether changes are merited include the following:

Maintenance costs—The network might be functioning nicely with equipment that is several years old. However, the maintenance costs associated with older equipment might be justification for upgrading to newer, more reliable equipment.

Existing contracts—Leased equipment can usually be purchased or returned to the lessor at the end of the lease period. Contracts that are about to expire should be examined and taken into consideration when deciding whether to keep the existing equipment or upgrade. Keep in mind the costs associated with migrating to newer hardware. For example, software licensing might be more expensive on higher-capacity servers, whether or not you need or use that capacity. Yet it is often the case that newer components will provide a better return-on-investment (ROI) than older technology. You should examine the costs for both of these options. The older the equipment is, the more likely the vendor will charge more for a maintenance agreement. The newer equipment may cost more, but you might find the maintenance costs much lower for the next year or two. Keep in mind that newer technologies are now based on a few years, not decades.

Network traffic—Regular monitoring of network traffic to locate bottlenecks or congested areas can be helpful. It may be that user work habits or procedures can be changed so that problems that occur only at peak hours or on specific days do not lead you into spending too much on a small problem that can be better solved by other methods.

Maintaining Support for Legacy Applications

There comes a time in every application’s life when it really should just die and go away. However, when you consider the costs associated with replacing a legacy software application with one that is state-of-the-art, sometimes what you find might lead you to listen to users who like their software and want to keep the application around a little longer.

The following are some hidden costs you might overlook at first glance:

Ongoing maintenance or support costs

Employee support costs

Infrastructure overhead costs

Maintenance and support costs can be hidden in part of the budget for the department that an application or a hardware platform supports. When multiple suppliers are involved, you will usually find multiple contracts, some of which even overlap each other. Another problem with ongoing support costs is that manufacturers raise these costs when products become outdated to help encourage users to adopt newer ones.

The number of employees you dedicate to a particular part of the network is an important cost. If you have a large staff whose responsibility is mostly maintaining an old application, consider the costs associated with them, from salary to overhead, and decide whether it might be better spent training them on newer technology and replacing the legacy system.

Legacy applications are usually either loved or hated by their users. Some people think with the mindset “but we’ve always done it that way” and do not want to change for fear of the unknown and love of the familiar. Other users who are used to better technology might hate a legacy application. The point to remember here is that it does not always matter what the user thinks about the application. What is most important to the business’s bottom line is how the costs associated with the change compare with the benefits the company receives.

What Resources Are Needed for the Upgrade?

If you already have a good inventory of the network, you are ahead of the game. Keeping an up-to-date listing of network components—including hardware and software, along with other pertinent information such as network addresses, serial numbers, manufacturers’ help-line numbers, and so on—is a task that, when done on a regular basis, will yield great results down the line.

Without a good network map document, you won’t necessarily be sure that you’re not violating some of the topology rules for your network. Before beginning to plan an expansion or the addition of new equipment, review documentation for that which you already possess. You might have some devices that do not need to be replaced. For example, if you already have network adapter cards or integrated adapters that support 10/100/1000Mbps, you won’t need to upgrade those machines if you move to Gigabit Ethernet.

Items that you should be sure to inventory include the following:

Workstations and servers.

Network adapters.

Hubs, routers, and switches. Consider replacing hubs with switches, because there is little if any price difference, and switches operate at a much faster bandwidth.

Test equipment. Depending on your equipment (from hand-held cable testers to high-end network analyzers), this can be an expensive item.

Workgroup and end-user software applications. Most of the newer applications require a much higher bandwidth.

Mechanisms used to exchange data with contacts outside the company. You may still be using an older 10BASE-T network, but a good vendor is going to be operating at a much higher bandwidth.

Management and control applications, such as SNMP, DHCP, DNS, and NIS.

When you examine your inventory, determine how the existing pieces can be used in an upgraded network. For example, it won’t do a lot of good to install a faster switch and hook a server to a faster port if the server is not capable of supporting the bandwidth. In such a case, upgrades to the server (or a replacement) would have to be considered as part of the plan. Although installing switches can dramatically improve performance in a departmental LAN, an older hub might be sufficient for a few more years in an office where network utilization is not high. Test equipment and management applications are not generally inexpensive items. Be sure to include the costs of upgrading these management tools when calculating the cost of the upgrade.

When determining your resources, don’t forget people. A major project of any kind should always have an identified set of team players that will be responsible for the project. A clearly defined project team will identify the person responsible for each aspect, such as purchasing, infrastructure, systems, and documentation. This will greatly improve communication during the length of the project, because a point of contact is identified for specific areas.

A project leader should be designated to be the focal point both for the project team and for others in the company who need to get information about the project or its progress. Each project team member should have a clearly defined role and area of responsibility. The area of responsibility is a very important one. As in any social interaction, overlapping duties can generate personal resentment between people working on the same project. When a clear, defined set of job responsibilities and duties is spelled out in writing, you have a better chance of achieving harmony among the team members.

A project team will work best when it is dedicated to the project. Giving users multiple roles to fill in their jobs can lead to confusion, unexpected priorities, and degradation in the progress of the overall project. Although the current support staff might be knowledgeable in the network and its quirks, bringing in additional help, by using experienced contact workers, for example, might keep the project focused on its goals and the time frame associated with them.

Planning an Upgrade

Planning is the process of deciding what actions are needed to accomplish a goal. This necessarily implies that the plan will describe the specific goals to be achieved and the benefits that will come from them. However, the steps that are required in a plan are dictated not only by the goals that are to be accomplished, but also by the following considerations:

How a network upgrade affects users (downtime)

What established corporate standards must be followed (or possibly re-examined)

What criteria can be used to measure the progress or success of the plan

Planning for an upgrade should include input from both technical staff members and the user community. After user requests (and complaints!) have been reviewed and a decision has been made as to what issues will be addressed, measurable goals can be established and written documentation can be produced that details the plan, its goals, and how the goals are to be achieved.

Documenting the Plan

Planning is essential in a complex environment to ensure that a project will be successful. Planning can encompass more than one document. For example, there can be a detailed plan that contains checklists for tasks that need to be accomplished, along with time-frame assumptions and resource requirements. For top-level department heads, an executive overview can serve to garner support for the project without forcing management to get bogged down in details they do not understand.

Whatever planning you undertake must be put into the form of a written document. Representatives of the areas that will be affected should carefully review any plans in order to solicit their feedback and ensure their cooperation. However, as with most things in life, even a good plan is likely to undergo changes during its execution. It is important to create a process that can be used to evaluate changes and incorporate them into the plan in an orderly manner. Put the process in writing along with the other details of the plan. If you have the plan in writing, it becomes much more difficult for a disagreeable person to protest when deadlines must be met and resources are limited. An orderly change process can always include a method for recording potential change ideas so that a decision can be postponed to a later date.

Reminding those who are working on the plan about recent accomplishments and upcoming deadlines can help facilitate cooperation. For example, a short meeting on Monday morning that quickly reviews the previous week’s work and includes a discussion about goals for the upcoming week might be helpful.

Evaluating the Plan As It Applies to Corporate Policies and Procedures

Before beginning to write any kind of plan that will be used for a major upgrade project, be sure to review the current corporate standards. A company should have one standard word processor that is used throughout the company, or at least throughout any major division of the business.

Most applications today that perform ordinary tasks, such as spreadsheets, word processing, or database functions, also come with tools that enable you to interchange data with other vendors’ products. Although this might seem to alleviate the problem of using multiple products for the same purpose, there is another factor to consider: end-user support. Even if data can be easily exchanged, the extra expense of having to support more than one application for a single function is an ongoing cost that doesn’t go away.

When developing the plan, first examine the current standards. Then, taking into consideration the future expansion of the network, the capabilities of products currently in use, and the direction certain technologies seem to be taking, develop a revised list of standards and sell it to the organization.

Of course, there will always be exceptions. For example, the corporate standard might require that the Oracle database application be used throughout the company. However, a specific vertical market application used in a research lab might work only with another database product. When there aren’t various vendors from which to choose, you might be forced to accept a deviation from the standard here and there.

Setting Goals

Any good plan will have a clearly defined set of goals to provide some kind of benefit to the business. Although an overall view of the project’s goals can be used to help sell the idea to upper-level management, the goals that should be included in a detailed project plan must be more specific. The following are two important reasons why you should have a defined set of goals:

If defined with enough detail, goals can give you something to gauge the progress of the upgrade project.

Goals can keep you on track, preventing you from getting sidetracked by other ideas that will inevitably come up during the project.

After you come up with a written list of the goals that will serve to guide the project, prioritize the list. When initially developing a list of project objectives, your staff might be over-enthusiastic, and you can find yourself with a large shopping list that attempts to solve every problem and please every department. Set realistic priorities based on the benefit each goal is expected to provide, and then remove items from the list that provide little benefit or do not address an immediate need.

Scheduling Downtime

Users should not be expected to understand what goes on behind the scenes in the complicated area of networked computer systems. They might only know that they can or cannot get their job functions performed in a timely manner because “the network is down.” By planning ahead and letting everyone know when resources will be unavailable, you will find that users are more likely to coop-erate.

Milestones and Criteria

Based on the goals that the project is expected to achieve, build into your plan the procedures that will be used to measure success. Select items from your list of objectives that represent major changes to the network and define the metrics that will be used to determine whether the goal has been met.

For example, a goal can consist of achieving a reduction in network utilization for overloaded segments. Monitoring utilization with a LAN analyzer can be done before and after the upgrade to obtain factual information that can be used to establish the success of this upgrade. Other metrics might include items such as network response times, user satisfaction, or new functionality. The last item is a little more abstract than the others are. How do you measure the impact of new functionality offered by a new application or network configuration? Look at the business function that it provides and find aspects you can measure. For example, if the turnaround time for a monthly billing cycle is usually 48 hours, and new faster servers or software cuts that time to only 12 hours, then this achievement should be measured and reported to management to justify the upgrade costs.

If you find that you are having trouble deciding what benefits you will gain from the upgrade and cannot devise a list of metrics, it is possible that you haven’t fully thought through what you are trying to accomplish. In that case, take time to re-examine your thought process that led you to decide on an upgrade. After you identify specific goals, rewrite your plan.

Back-Out Procedures

Nobody is perfect, and no plan can ever be precise enough that you can bet your life that everything will go as expected. Whenever possible, for any major modification you intend to make to the network, you should also have a plan that can be used to restore the network to its previous state. Having good up-to-date documentation about the network can be useful for troubleshooting. When you have scheduled downtime with users and are under a deadline to finish a task or a project, it is more useful to have a definite set of procedures to follow if problems arise that prevent the execution of a task or tasks in the project plan.

A back-out plan does not have to include abandoning the entire plan. Most network upgrades do not occur all at once, but are instead done in stages. At each major step in the plan, have a procedure that can be used to undo the change.

Testing the Plan

The complexity of networking technology today makes it important that you test new equipment and software before committing it to production use. You might find that devices do not function as you expected when deployed using your planned configuration. Management software might be cumbersome and difficult for technicians to understand. In the end, if the technicians and end users are not satisfied and cannot perform their jobs efficiently using the tools you provide, it is likely they will complain to your management. Some of them may even try to find their own solutions, which can significantly increase the hidden costs of your upgrade.

During the testing phase is when you’ll probably find the most changes to the plan. When tests show that performance doesn’t meet your expectations, the plan will be changed and performance measured again. During testing, the laboratory environment should closely mimic the proposed production network.

Evaluating Competing Products

Careful selection of new equipment or software up front can save time and money after the upgrade is finished. Evaluate competing products carefully so that you can select those that best meet the goals of your upgrade plan. When looking at different vendors’ products, try before you buy. For a large hardware purchase, many vendors will loan equipment for a trial period so that you can make a better determination as to its suitability to satisfy your needs. Almost all major software applications can now be obtained from a vendor in a “demo” or “evaluation” copy so that you can test the features.

Another very important factor to consider is the vendor itself. You might find a great product that looks as though it will work miracles for your network. However, if the vendor is not reliable, what will you do when you encounter problems later? Things to think about when choosing vendors include the following:

Responsiveness—Do you get through to the help you need when you call the vendor, or do you have to play telephone-tag to get answers?

Availability—Does the vendor have a good stock of products, or will you be subjected to back orders that can take days or weeks? When you have to replace a part due to malfunction, can your network wait until the part arrives?

Service—Does the vendor provide service for the product? Is on-site service available or do you have to return the item to the vendor for repair?

Training—Does the vendor provide training for the product? Is the training of good quality?

Price—Price usually comes into play when a product is a commodity item. For specialized products or applications, price might not be as important as the other items listed here.

The Pilot Project

Every good plan should include a pilot project. This involves taking a small part of the network, such as a network-friendly department, and implementing part or all of the project modifications in that localized area. Not only will it help you determine whether you have made the right choices for new hardware or software, but it also will help you further refine the installation procedures that will be used to execute the rest of the plan.

If it is not possible to do this in a “live” environment, create a test lab where you can simulate the production environment or network. Use script files to automate processing and perform stress testing on the new components or applications to see whether they really perform as you expect.

The results of a pilot project or a test lab setup can be used to refine and modify the plan and make it more likely to succeed.

During the pilot project phase, try to avoid “mission creep” (adding goals to the mission the upgrade is designed to perform) and “feature creep” (adding features to the network). Mission creep and feature creep at any point, especially near the end of the implementation process, causes delays, dissatisfaction, and could cause the original objectives of the upgrade to be overlooked or lost. To help avoid these problems, carefully evaluate the goals of your upgrade and the new features it will add to your organization before beginning the process.

Deployment

After you have evaluated and re-evaluated, tested, and retested, and are sure that your plan is a sound one, implement the plan to upgrade the network. Depending on the scope of the upgrade, the deployment stage can be done all at once, or it can be done in a migration process over time. Adding segments to a network for new offices or replacing older cables can be a simple matter accomplished over a weekend. Migrating a large network to a faster topology might require that you deploy only small segments at a time to ensure that disruptions for users are minimized. An application upgrade can take longer to implement because of such factors as data conversion and user training.

Team Personnel

The personnel who are employed to perform upgrade functions should be well trained far in advance of the actual deployment stage. Each person should be knowledgeable in the area of expertise for the functions he or she will perform. To aid the upgrade team, it is a good idea to have specific written task lists that describe what is to be done. For example, a recent network upgrade in which I participated required that network adapter cards be replaced in a large number of workstations. The process involved the physical action to remove the old card and replace it with a new one.

After the card replacement, however, there were additional chores to do. For example, each card had to be configured with the correct drivers so that the operating system would be capable of using of it. Each workstation had to be tested for connectivity to ensure that the card was correctly configured to work with the network. The task list for this was written in detail describing each step the team member needed to perform, and included a check-off box for each step. Why a check-off box? If you have to take the time to check off each step, you are less likely to forget one. When a person is performing the same actions over and over, moving from workstation to workstation, the odds are likely that mistakes will be made. This is especially likely if you need to customize the default configuration. For example, if you have Windows 98 clients browsing a Windows XP or Windows Server 2003 system for shared resources, you should disable the QoS Packet Scheduler service normally installed on Windows XP or Windows Server 2003. Because Windows 98 clients don’t use QoS, having it present on servers can cause enormous delays when browsing shared resources.

It is also a good idea to designate one or more persons to be a resource focal point that team members can use when problems arise. If one person is aware of the problems that are occurring, it is easy to implement a fix throughout the project so that the same problem doesn’t have to be solved over and over.

Keeping Users Informed

Network users should be kept current about the progress of the upgrade. At the beginning of the deployment stage, present the users with an overview of what will be happening, when it will happen, and how it will affect their work. As specific tasks are ready to be done, let the users who will be immediately affected know shortly before you begin. For example, if you plan to replace workstations throughout the enterprise, create a list of replacement candidates each week and notify the affected users via a memo or an email so that they will be reminded. For an extended project, it is easy for users to forget what you told them weeks or months earlier.

Along this same line, it is a good idea to get some kind of response from a user when you have made changes to his workstation. For example, having a user test the system for a day or so and then “sign off” on the work lets him know that (for him at least) the process is complete; this is known as user-acceptance testing.

Tracking Progress

Use the metrics that you designed to measure the progress you make as you implement the plan. It is important to keep track of the progress so that you can coordinate your people, your resources, and the delivery of additional equipment or outside services. If you are falling behind in one area, you may have to reschedule tasks in other related areas. Keeping a close watch on progress is necessary so that you can quickly detect when something is not going as expected and begin to come up with an alternative method for getting things done.

The mechanisms you can use to track implementation of the plan might include a spreadsheet, a diary-like text file, checklists, and so on. To present information to upper-level management, you might find that weekly or monthly summary reports help in keeping their support. If you find yourself in a position where you need to report on progress to high-level managers, graphical displays, such as graphs or charts, can help get your point across. If you are creating a presentation, it can be helpful to restrict your use of clip art to illustrations that convey additional information. No one will be impressed by your ability to use every stick-figure included in PowerPoint’s clip art arsenal.

User Training

The topic of training can cover a large territory. Users should be trained to acquire the necessary skills needed for new applications or new ways of doing ordinary tasks when the network changes. In-house personnel who have the skills and the time to devote to the process can do training. For large projects it might be more economical to employ outside resources for training users. Additionally, there are various training resources you can make available to your users for most popular applications. These include training videos, computer-based training (CBT) applications, programs presented by user groups, and so on.

Make users aware of the resources at their disposal from the beginning, and begin training before major changes are made so that the users will be better able to cope with the new environment. Users who are trained in advance for a new application or procedure are less likely to cause a strain on the upgrade team’s resources while the upgrade is proceeding.

Closing the Book—Documenting What Has Changed and Why

When a major project comes to a close, it is a good idea to compile a short report that details the project, from the evaluation and planning stages all the way through to the deployment and user-acceptance stage. This historical document can serve in the future when it comes time to take on another project of a similar scope. It also can be presented to management to make them aware of the scope of what has been accomplished. This visibility can be very beneficial to a network administrator’s career!

Other Considerations for Upgrading

Undertaking a major upgrade to a network is not a task to be taken lightly. As with any large undertaking, it is best to try to accomplish your main goals with the least amount of excess baggage. With a large number of users, it is easy to become overwhelmed with the volume of suggestions or requests when the user community finds out that major changes are being planned. However, for each additional task you add to your plan, you also add to the probability that something will go wrong. So, after deciding on the basic goals, try to stick to only the tasks that will be needed to accomplish those goals and do not get sidetracked by unimportant issues that can be best settled later.

However, you should consider this time to be an opportunity that can be used to incorporate new technologies or functionality into the network that otherwise would require additional downtime for the network. For example, if you are about to begin upgrading user workstations throughout a department or an enterprise and you have been considering adopting DHCP, what better time to do so than now? If you are already going to put the user out of work for a short period, and the workstation is off the network, this kind of situation is ideal for bringing in a new administrative tool such as DHCP.

Housekeeping is another function that can fit nicely into an upgrade plan: Out with the old and in with the new, so to speak. Old programs that never quite went away can be removed during an upgrade process. An upgrade can be a good time to set a deadline for users who have not yet abandoned older applications that can be better performed by newer applications.