Phased Implementation of SLM

Effective SLM has many facets, and an effective process is needed to minimize deployment problems and to ensure solid service management capability in a variety of environments. As is true for any systems project, the project implementation plan involves selecting technologies for each functional area and then selecting a vendor or vendors that meet specific needs. In addition to technology and vendor selection, there must also be a process that outlines the steps needed to complete the implementation project.

Implementing an effective SLM system usually requires a phased approach. Using phases offers several advantages, but the primary advantage is breaking down a set of complex, expensive, and critical processes into smaller, easier to manage steps. Another advantage of phases is that there is an opportunity to pause after each phase and determine if changes to plans are required before proceeding. It also spreads expenditures and gives the management team a chance to show value early.

Choosing the Initial Project

Successful SLM is the product of deliberate analysis, planning, implementation, and ongoing learning. It bears reiteration that the first project chosen for SLM will be a test bed for new methodologies; therefore, the customer must be prepared to accept some new concepts and some intermittent problems in return for the opportunity to obtain better service. Service Level Agreement (SLA) wording, definition of metrics, and service level objectives along with their statistical treatment will probably be new to the organization. Accompanying these will be the need to handle integration and grooming of instrumentation measurements, changed problem management techniques, and service level reporting.

An application that depends on service levels may already exist; for example, many legacy transaction systems are given priority on internal enterprise networks, and Voice over IP (VoIP) systems usually are given priority on LANs. These prioritizations are commonly based on rudimentary packet or frame tagging and on simple priority queues within routers and switches, usually without a comprehensive system to report on and manage service levels. Moving one of those applications to a new, more integrated SLM methodology is probably the smoothest first project. The migration can provide an opportunity for staff who are already involved with service level techniques to learn the new methods. The staff can also bring their knowledge of the organization's needs into the initial development of the new SLM systems.

It's also important to choose a pilot implementation in which end users can review plans at critical junctures. Some of this is common sense. SLM helps address the needs of users, so asking their advice can help avoid blind spots. Allowing users to participate, or at least to observe, also lets them buy into the learning process. If users are part of the process, they will probably be more forgiving of the inevitable mistakes and delays.

If there is no existing application already using some type of service level technology, it's probably best to pick an application that uses a limited subset of the enterprise's systems, instead of trying for a global initial project. The fewer the number of different subsystems and providers involved, the less complexity that will have to be addressed in this first trial.

Note that a simpler environment also exposes problems more clearly, and the implementation team learns more quickly. However, limitations in scope must be balanced with the need to detect upcoming implementation problems. Subsystems and providers that are widely used in the enterprise should be included in one of the earlier SLM projects even if that increases complexity. One or more of those subsystems or providers might have an incompatibility with the chosen SLM technologies, and it's better to detect that problem early, before the momentum for a particular set of SLM technologies has grown.

Incremental Aggregation

It is best to introduce and activate new services in small increments. Each service can be monitored for a trial period to ensure that baseline service quality and stability are maintained under a variety of loading conditions. At that point, the service can be incorporated into early SLM projects, and continuous monitoring for compliance can become part of the regular management routine.

Further projects can be brought online as soon as the initial set has been proven successful. This increased use of the service through aggregation of the needs of multiple projects has advantages both in building on a now-proven SLM and service technology and in negotiating more favorable terms with service providers. For example, aggregating the projected bandwidth demands from each business unit into a single acquisition gives the organization more leverage in obtaining bulk discounts or other benefits. Using the initial pilot as a "teaser" for the supplier, with the promise of additional projects from aggregated additional needs, can provide important negotiating leverage.

This iterative process may appear slower in the beginning, but the phased, gradual approach is useful. There are usually gaps between the projections of resource requirements and the actual conditions. Ongoing measurements can be used in the phased approach to determine if resource adjustments are needed before more services are added.