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 cooperate.

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.