Networking Solution Implementation Considerations

The implementation of a networking solution is a distinctly different stage from its design, but it is a good idea to keep the implementation considerations in mind during the design stage. For example, if the implementation is going to require a significant amount of system downtime and disruption to normal business operations, you should consider that during the solution's design. You should incorporate appropriate recommendations in the design document regarding when would be the best time to proceed with such an implementation.

Figure 1-2 illustrates a designer's balancing act between the process of a solution's design and its implementation. When the desire to go through the design process is in balance with the desire to implement, it is deemed to be the optimal condition for ultimate success. Getting caught up in an endless design spiral or taking the rash approach of plunging into implementation without a design or only a cursory one carry corresponding risks of not getting anything done or producing something that simply does not meet the business requirement for a networking solution.

At a minimum, generic implementation considerations include the following:

• Sources of implementation expertise

• Project management during implementation

• Performance testing

• Documentation

• Training

Sources of Implementation Expertise

Any networking solution is going to require either internal or external IT resources to implement. Use of internal resources can be a sore point with the IT departments at SMBs. The internal IT staff already tends to be overworked and often feels underappreciated and inundated with new projects, which is one of the reasons that the IT department was identified early in this chapter as one of the stakeholder categories. You need to ensure that the IT department's input is taken seriously and that the IT staff supports the project at every level, including who does the work after the design is completed.

The external implementation resources include the solution's vendor, partners, independent consultants, and contractors. The size and nature of the solution will determine the makeup of the implementation team. The key is to spell out as clearly as possible who is responsible for what aspect of the implementation. If internal IT staff are going to be involved in the implementation of a large, resource-intensive solution, it's a good idea to identify which of the tasks that are currently being performed might not get accomplished as a result of such a diversion of internal resources. This approach keeps surprises to a minimum!

Project Management During Implementation

Implementing a well-designed solution ought to be a lot easier than jumping into implementation without going through any kind of a design process. Both processes (design and implementation) are projects that require their own unique forms of project management.

During the design stage, you collect and analyze the requirements, negotiate with the stakeholders, consider all of the advantages and disadvantages of topology, define performance criteria, and, finally, submit the requirements to the budget ax to come up with a final design document, which you hope represents a consensus of all parties involved in the design process.

During the implementation stage, you ensure that what has been installed meets the performance criteria, is within the allocated budget, and is being delivered on schedule. You are potentially dealing with vendors who must deliver the solution in its entirety or components thereof according to an agreed-upon schedule. You have to plan for contingencies in case delivery deadlines are missed or performance criteria are not met.

You have to deal with the almost given fact that no matter how careful the design is, not everything is going to work out as planned during the implementation. There has to be a degree of flexibility and willingness to adjust the design even in this late stage. This is similar to how jobs proceed in the construction industry; there are architectural plans, and then there are “as-builts,” which are plans that reflect what has been changed from the original.

It is certainly a judgment call whether or not the design team will also manage the implementation. Whoever takes on the job of project management during the implementation needs to understand the design well and be able to communicate well with vendors and stakeholders about how the implementation is proceeding and if there are any changes from the original design.

Performance Testing

Performance testing requires that performance criteria be clearly defined, as is recommended during the draft design and review stage. Here is the real question: What happens if the solution does not perform as specified?

If the solution does not perform according to criteria specified during the design, and the solution has not replaced a preexisting system that a business relies on, the decision boils down to whether to tolerate the lower level of performance and proceed with the implementation. Obviously, there are going to be financial implications for both the business and the solution provider that result from an unacceptable level of the solution's performance, but at least the current system is still in place. However, if a proposed solution irreversibly replaces a functioning system, the end result could be anything from an agreement to have a fix in a reasonable period of time, to lower or no pay to the solution provider, to possibly a lawsuit.

Ideally, the solution provider should understand the level of a solution's performance long before implementation. In fact, performance might be one of the solution's selling factors. So the idea of performance testing should be a verification mechanism where the outcome is reasonably certain. If possible, the solution's performance should be demonstrated in a test or prototype environment during the design stage and/or by running in parallel at the time of implementation.

Running in parallel means that the new solution is operating side by side with an existing one. That's sometimes easier said than done. And even if you take this approach, whether or not the solution performs as specified is generally revealed only when you go live with it and subject it to the stress levels of the actual operating environment.

If you choose to run in parallel, remember that it takes additional resources to maintain two systems side by side. But the effort might be worth it if you simulate the appropriate stress level on the new solution. Running in parallel often involves software-based solutions with a lot of transaction processing and potentially significant changes to the underlying databases. A situation in which you switch between CRM systems would certainly be a candidate for running in parallel, but so would an implementation of an IP Telephony solution that replaces a traditional PBX.

Documentation

The topic of documentation is controversial, with good cause. Detailed documentation tends to become obsolete as a result of ongoing changes and upgrades following a solution's implementation. To keep documentation up to date, someone has to maintain it on an ongoing basis, which is a task that often goes by the wayside. In addition, documentation that is too high level is often viewed as useless.

Documentation is necessary but, as is the case with training, it needs to be targeted at different groups of stakeholders. Examples follow:

• An executive summary with a few color diagrams might be all that is required to satisfy the documentation needs of the management.

• The end users might require a cross-referenced manual with screen shots, descriptions of procedures for dealing with different customer issues, explanations of tables and fields in a database, keyboard shortcuts for accomplishing common tasks, or instructions on how to use more complex networking equipment.

• The IT department might be completely satisfied with documentation that is in the form of online help or that can be derived in real time via network management tools.

• A business that is subject to external financial or security audits might need to provide documentation of its network that is satisfactory to the auditors. These documentation requirements would normally be understood by the business and would likely be stated during the stage of identifying the stakeholder requirements.

Regardless of the nature of a solution or the customer, a balanced, targeted documentation is an essential component of any solution implementation. It does not make the success of the solution contingent on contact with the provider; rather, it allows the business to take maximum advantage of the solution's potential.

Training

Often, little consideration is given to the training aspect of a networking solution implementation. To take maximum advantage of a solution, training is required at all levels of implementation. What a pity it is to see people use the absolute minimum set of a solution's features, just enough to get by, due to lack of sufficient training.

There are many ways in which the value of a solution can be minimized and even outright compromised because of lack of training. Take security, for example. Plenty of routers, firewalls, and IDSes simply are not properly configured or sufficiently fine-tuned to take full advantage of their features. There are even firewalls that permit all traffic to go through them. How about that for a false sense of security!

The key to successful training is to identify the appropriate target audiences for the different aspects of required training, make the training relevant to the solution at hand for each audience, and conduct it at the right time. Ideally, training ought to occur in several stages:

• Prior to the implementation— Training before implementation should concentrate on the solution's capabilities and the changes in existing procedures that the solution will introduce. If the solution involves a software application like a CRM, for example, it is useless to talk too much ahead of time about specific screens or keystrokes if the users are not able to use hands-on experimentation during the training. On the other hand, if the implementation procedure calls for having a test system prior to going live, that's the time to start getting all of the users used to the new solution.

• During and/or immediately after the implementation— Training during or immediately after implementation might fall into the category of user support at the earliest stages of going live with the solution. You want to make sure that whenever a new solution is implemented, users are not left to fend for themselves if problems occur. This type of training tends to be perhaps more informal and hands on than training that occurs prior to the implementation.

• At a future time following the implementation— Future training falls into the category of optimization. After a solution is put to use for a while, the designers and implementers should review its use and ensure that the solution's capabilities are being put to maximum use. If that is not the case, additional training is necessary. This training should incorporate user feedback as well as observations about the solution's use from the designers and implementers.

Most effective training incorporates a combination of training tools, including formal presentations, demonstrations, hands-on practice, question-and-answer sessions, as well as some type of assignments to be completed by the trainees. Self-study is also an important aspect of the overall training program. The implementation team should do everything possible to facilitate self-study by providing access to the new system in a simulated and/or live environment in which damage is not possible as a result of trainees' actions.

There are also creative ways in which an SMB can take advantage of information and resources during implementation that will complement the formal training process without placing additional strain on the budget. For example, make sure to take maximum advantage of the technical expertise of the vendor supplying the solution. There might be free white papers, free online training, or books that would complement the training being offered. Explore the training sources. Even if a solution provider does not usually offer training, it might be something that you could negotiate. Consider training a smaller group, who can in turn train others within the business.