This article is the second in a series on best practices for service delivery as it relates to translating customer needs into network services.
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.
In summary, flexibility is enabled in a project plan through proper planning, communication between groups and a well developed contingency 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.
