Sometimes the technology aspect of delivering network services is fairly easy; it's understanding and managing the customer's needs and expectations that's most difficult. In this guide you'll find a checklist for defining customer requirements best practices for developing flexible project plans that emphasize communications and contingency and recommendations for an implementation plan that minimizes integration problems and deployment delays.
In this guide:
Checklist for defining customer requirements
Best practices for flexible project plans
Essentials for painless implementations
Checklist for defining customer requirements
Network services can be defined many ways. Some examples include deployment of VoIP and video over IP services or business critical applications like SAP CRM or Citrix which depend on the network to function. The majority of organizations today rely heavily on the network and network service delivery capabilities to run their businesses. In most cases there are usually technology modifications or deployments required to enable those network capabilities and services.
Business requirements drive technology initiatives. Therefore understanding and capturing the customer's most important business requirements and translating those into technical requirements and technology solutions is a critical aspect of successful network service delivery.
Gathering requirements is an intensive process. In general there are three key areas of requirements that need to be addressed. The areas are:
- Business requirements
- Technology and technical requirements
- Integration requirements
Business requirements
Business requirements focus on understanding where the customer is going in terms of future expansion into new markets deployment of new service capabilities funding and executive vision for the organization. In most environments it is a business decision that drives IT initiatives.
The IT department is responsible for network reach support for mission critical application delivery and uptime and performance of the network. Sometimes the IT department communicates with the business units and vice versa but at other times IT is in reactive mode.
It is recommended to define and capture business requirements up to three years out to determine what network services will be needed to support the customer's business.
Technology and technical requirements
Technology and technical requirements are defined after business requirements and are in fact driven by the business requirements. Technology requirements include determinations of vendor alignment and standardization requirements. The technical requirements are details of the design of the solutions that will be deployed to support the business services. The business is enabled via applications delivered over the network so there are key technical requirements that must be addressed including:
- Architecture requirements: These provide input to decisions around major network technology decisions in key areas such as LAN and WAN datacenter and operations. Examples include MPLS for WAN transport data center consolidation and centralized versus distributed IT operations.
Bandwidth and scalability requirements: These define where application services need to be delivered and how much bandwidth is required. This drives decisions around WAN reach and remote access as well as infrastructure sizing.
Integration requirements: These requirements drive technology decisions such as vendor functionality and interoperability with the current systems.
Management Requirements: These define how the network will be managed from a fault configuration and performance aspect.
Security requirements: These define how application services will be secured. With new federal and state regulations requirements for restricting access authenticating users and encrypting data in transit and at rest all need to be defined.
Integration requirements
Integration requirements define the deployment process timeline tasks and resource allocations necessary for the customer.
Some key questions to ask related to integration include:
- Does the customer require project management for deploying new network services‾
- Has the customer defined all of the tasks that are necessary to deploy new network services‾
- Has the customer identified the timelines for deploying the new network services‾
- Does the customer have the internal resources necessary to deploy new network services‾
- Has the customer developed a detailed project plan to drive the execution of the project‾
Each and every one of the requirements above must be defined and understood. These requirements drive actual decisions or activities related to deploying new network services and can go a long way in facilitating success.
Best practices for flexible project plans
Project plans are one of the tried and true mechanisms for managing service delivery and complex integrations with many moving parts. Many methods have been used for tracking project status and completion including Excel spreadsheets and Microsoft Project. This article is not intended to discuss specific tools but instead outline an approach to developing a project plan that can be used effectively to drive projects to completion.
Project plans by their very nature are inflexible in most cases. Project plans are defined by sequences of events that can occur in parallel or in sequence with interdependencies and predecessors sprinkled throughout the project. A perfect example of this is deployment of network gear being dependent on the ordering and procurement of the equipment. The deployment task cannot commence until the ordering and procurement task is complete. This being said reality is that not all projects go according to plan and there needs to be a degree of flexibility in the plan.
A good project plan begins with defining all of the touch points for the project. In a typical network services deployment project that includes the configuration and installation of new gear or the reconfiguration of existing gear the following groups are commonly used to support the deployment:
- Architecture and engineering team
- Site contacts
- Site readiness team
- Provisioning team
- Staging team
- Field integration team
- Field testing team
- Network operations
- Corporate communications
- Project management
Each of these groups represents different areas of the organization and input from all is required to develop the overall project plan. Best practices require that a representative from each of these groups participates in the planning process. Gathering all of the representatives in a room and defining goals objectives and timelines up front allows all parties to know their responsibilities. Once these are defined a discussion on interdependencies and constraints should be considered. This allows all parties to understand that contingencies must be defined.
Communication between these groups is critical to flexibility. If all groups understand the roles responsibilities constraints and interdependencies then a contingency plan can be developed that allows for flexibility in moving milestones up or down within the project timeline. The flexibility to move site conversions up or down based on contingency planning is the critical component to being flexible with the project plan and execution of the project.
A perfect example of this is a contingency plan for a MPLS WAN migration. These migrations have hundreds of thousands of moving parts and the scheduling of all the tasks timelines and resources is a major challenge. In most migrations delays do and will occur creating the need for flexibility in scheduling of site migrations. A proven approach is to categorize sites as high medium and low risk. The low risk sites are added to the project plan with the understanding that these sites may move up or down within the schedule to maintain the timelines in the event of delays. This provides a tremendous level of flexibility for the project and minimizes the risk of falling significantly behind schedule.
Essentials for painless implementations
Painless implementations start with proper up-front planning. No matter how beneficial a customer's new network services will be implementation problems can erode financial benefits and create doubt regarding the true capabilities of the new services. Implementations usually require installation and configuration of new equipment. Without proper planning this can be a disaster both from a timeline perspective and an actual integration perspective. Delays and adverse impact to the network should be avoided at all cost.
Deployment planning should focus on the following areas:
- Robust architecture
- Standardized configurations and detailed design
- Procurement
- Site readiness
- Scheduling and resourcing
- Change management
- Site turn-up
- Site testing
- Operational handover
Each of these areas in itself can contribute to implementation missteps and problems so clearly understanding the essential areas of focus in each is important.
Robust architecture
A robust architecture is one that defines all aspects of the architecture including the desired features functionality and capabilities as well as integration into the current network and visibility from a management perspective. If the new network services are enabled via a new technology with which the organization has no prior experience it is highly recommended that proof-of-concept lab testing or piloting of the solution take place prior to deployment.
Standardized configurations and detailed design
If possible standard configurations should be created for the network elements delivering the network services. Many installation efforts fail due to inconsistencies in the configuration of the gear during deployment and difficulty in troubleshooting within a non-standard environment.
A detailed design should be developed that outlines the configuration specifics for each site. This should be done prior to deployment so that equipment-specific or site-specific information can be tied directly to the design details of the sites including port mappings interface naming host naming IP addressing VLAN addressing dial plans and other numerous site-specific configuration parameters. In all cases providing specific site configuration details and standard configuration templates up front reduces errors during deployment.
Procurement
There is nothing like botching an installation due to the equipment not arriving on time receiving the wrong equipment or having equipment dead on arrival. The procurement process must include contingencies for all of the above and robust communication channels to notify of delays prior to the implementation window.
Site readiness
No matter how well the architecture has been defined and the configuration details sorted out if the site where the changes are being made is not ready for the change none of the other implementation plans matter. Site readiness should consider space power and HVAC requirements port availability and demark extensions at a minimum. There is nothing more frustrating than failing to turn up a site because no one at least eyeballed the equipment room to ensure there is space for the equipment.
Scheduling and resourcing
Getting the right resources to the right place at the right time doing the right tasks is essential to any successful deployment. Implementations are resource dependent and do not happen on their own. Poor planning in this area is a recipe for failure.
Change management
Most organizations require that some form of change management process take place to review schedule and communicate changes within the environment. Change management can be process intensive and in some cases constrained to certain windows of time. However not adhering to the process can bring the scheduled installation to a screeching halt.
Site turn-up
Site turn-ups require resources to install and configure the network elements to deliver new network services. Having a well documented installation and configuration script (list of tasks) is essential to guiding the turn-up resources through the installation in a predefined manner.
Feedback on improvements and nuances learned through the turn-ups can provide a mechanism for defining the optimal sequence of tasks.
Site testing
Site testing is most often overlooked as a part of the installation. Testing of the network functionality is a given but in addition application services should be tested. Having a typical user workstation execute normal day-to-day tasks can provide a level of reassurance that the network is working as designed.
Operational handover
There should be a standardized process for turning over the network to the operations team post implementation. This allows for day-two management to commence and for any issues to be addressed by the operations team rather than the deployment team. Having the deployment resources also support the day-two management can stretch resources thin and impact the deployment significantly. In addition to defining the process for handover the operational team should be trained on the technology prior to deployment.
All of the above areas if not addressed up front can severely impact a successful deployment. It all comes back to proper planning and execution of the plan.
About the author:
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for AT&T. He has more than 10 years of experience providing strategic business and technical consulting services. Robbie lives in Atlanta and is a graduate of Clemson University. His background includes positions as a principal architect at International Network Services Lucent Frontway Callisma and SBC Communications.