The project plan explained in this appendix is an example of how a team can plan, manage, and track an enterprise-class WLAN deployment. For illustrative purposes, the project plan makes certain assumptions and is limited to a relatively small business. The concepts and approach are the same, however, for larger deployments. For this example, the project commences on the first Monday of 2005 (January 3, 2006).
The project plan is not intended as a comprehensive tool or reference, but rather as an example of how a hypothetical corporation should manage a deployment. Because most organizations have their own approach to project management including using one of the many public domain methodologies. It is important to develop a customized project plan in line with whatever methodology you adopt and use the example in this chapter only as a reference and inspiration for initial planning and discussion.
You can find copies of the project plan Gantt chart at the Cisco Press website dedicated to this book. Please go to www.ciscopress.com/title/1587201259 to find a PDF of the project plan for your review, which you can use in conjunction with this chapter.
Example Ltd is a medium-sized enterprise with seven offices spread across California. Their corporate headquarter (HQ) campus consists of three buildings, including one light manufacturing plant, and houses 200 staff. Their six satellite offices are detached buildings and house between 5 to 90 employees each. Their two smallest sales offices are excluded from the deployment, so five sites are identified for coverage. Example Ltd has a centralized IT department based in the HQ and a varying number of local IT support staff at its five largest sites.
The project plan is organized into 11 separate sections. These are not necessarily in temporal order because several tracks are contemporaneous with each other. You may wish to organize your own project plan along different lines, or in line with your adopted project management methodology. The sections of the example project plan are as follows. Each section is discussed in this appendix:
Business Issues
Discovery
Architecture
Design
Testing
Logistics
Pilot
Communications
Support
Deployment
Post Project Activities
The Business Issues section deals with the initial business-related issues and is primarily, but not exclusively, concentrated at the beginning phases of the project.
A project kickoff meeting is planned, and the business goals are reviewed with a “go/no go” milestone following. No other effort can proceed before this decision.
A project steering committee is created and regular monthly meetings scheduled. For this small project, the project steering committee includes not only the executive sponsor and IT manager but also the project manager and his senior network architect.
Note
In larger deployments, the project steering committee is usually an executive body that meets on a regular basis and is updated by the project manager on project variances. The project steering committee usually includes the executive sponsor of the initiative and senior representatives from IT, HR, finance, facilities management, and so on.
The steering committee defines the scope of the project, including identifying which sites will be covered. In our example, the committee decides to exclude the two small sales offices. A list of site owners (local business and IT contacts) creates a request for comment (RFC) for both the wireless equipment and the cabling.
The Discovery phase is concentrated at the beginning of the project lifecycle. In this section of the project, the steering committee sets aside four weeks to evaluate the equipment from various manufacturers or solutions providers. This is sometimes known as a “manufacturer bake-off” and is a detailed testing, evaluation, and selection process where the enterprise tests the shortlist of products, usually in a lab environment, and selects the one most appropriate to the enterprise’s need.
The equipment is finally selected, and pricing and contractual negotiations follow. For the purposes of our sample project, it is assumed that a WLAN controller-based solution is selected. Once selected, the enterprise purchasing department signs a contract for the supply of the equipment.
The selection of a cabling contractor occurs simultaneously because this choice is independent of the final equipment used in the deployment. The RFC is sent to various vendors, and their responses are evaluated. By the time the steering committee selects the equipment or solutions provider, the cabling vendor should also have been identified.
The Architecture section deals with the development of the high-level solutions architecture. An architectural team is defined and regular monthly architecture meetings planned. The architecture team will probably be limited to senior technical staff consisting of network, operations, and security architects. The architecture team will report to the project manager and ultimately the project steering committee.
Note
This architecture team can be considered the main drivers, reviewers, and approvers of the solution but will probably not be involved in the detailed and specific design and configurations. In some organizations, the architecture team and the detailed design team are the same.
The architecture team defines the high-level architecture for the solution, ensuring it is in line with business drivers and requirements of the steering committee. At this stage, the team also defines the security architecture. Finally a week is set aside for business review, and an architecture document is created. The business review is where the steering committee and the CEO (in our example) review the architecture and validate that it satisfies the business goals. This is a major milestone.
After the WLAN architecture has been defined and approved, a detailed technical design can commence. A technical design team is created and weekly meetings scheduled.
Note
While the architecture team tracks technical progress against the high-level solution architecture, the design team is responsible for the detailed design, settings, and configuration of the equipment. In some deployments, the architecture and design team would be combined into one team; that is, both functions would be carried out by the same individuals.
Six weeks are set aside for drawing up a detailed technical design. This is subsequently updated with changes that arise as a result of the test plan (see the following section, “Testing”).
After a period, the detailed design document is once more revisited and updated. These updates occur after the pilot and reflect responses to gaps, customizations, or tweaks that come to light during the pilot.
A final detailed design guide is eventually completed. This is a major milestone.
The design team creates a lab that reflects the initial technical design, and it is integrated with Example Ltd’s existing authentication and entitlement infrastructure. Three weeks of testing follow, and the results are documented. The findings affect (positively or negatively) the technical design, as mentioned in the previous section.
The Logistics section deals with the logistics of equipment ordering and delivery. Equipment is ordered and delivered to Example Ltd’s HQ; 30 days of lead time are included by way of example.
Staging follows, where the equipment is unpacked and tested, and deployment packs are created for each site. These include the equipment required for each site, installation instructions, schematics, and so on.
Two weeks are set aside for delivery to the four satellite offices.
After the project “go/no go” milestone is achieved, a pilot site is identified. A pilot site kickoff meeting is held and a pilot design guide is created, based upon the initial technical design created (as detailed in the Design section earlier). Pilot site documentation and user communication collateral is created.
The pilot installation follows, with floor plans imported into the management and planning tool, the location of APs defined, the WLAN controllers and access points installed, and the pilot site finalized for use. Users are notified, and the pilot commences. For the purposes of this plan, it is assumed that the pilot lasts approximately 10 weeks.
User feedback is collected, documented, and analyzed, and the technical design is updated to reflect the pilot findings.
The Communications track does not lie on the critical path and as such can commence early on in the project lifecycle. A communications team is defined and an internal solutions program website is created. Project and site communication packs are created. User guides, FAQs (Frequently Asked Questions), and helpdesk scripts are also developed by the design team, in partnership with any dedicated HR communications staff available.
The Support section deals with the activities relating to solutions, technical support, and maintenance. A week is set aside to define the Service Level Agreement (SLA), and the support plan is documented. Training material for the technical support helpdesk team is produced in conjunction with the design team, along with more detailed second and third line troubleshooting and training collateral.
The Deployment section details the tasks associated with the installation of the solutions infrastructure. It is assumed that each of the five sites will be deployed consecutively, with Example Ltd using many of the same centralized IT staff for each deployment.
The deployment only commences once the final technical design guide is complete, including updates from the test plan and pilot.
The deployment itself follows closely that which was undertaken for the pilot. Floor plans are imported into the management and planning tool, AP locations are defined, WLAN controllers and the access points are installed, and three weeks are spent on client communication and training. WLAN client adaptors are distributed to end users who are not provisioned with wireless-ready laptops—that is, laptops that already have wireless cards embedded.
The site is then launched into production. By staggering the launch of each site, high support overhead is avoided, and the IT support staff are free to deal with end users on a site-by-site basis.
After the last site is complete, the post project activities are undertaken. A week is spent analyzing end-user satisfaction and feedback. A Post Project Review document is created that incorporates an initial return on investment (ROI) and “lessons learned” section. Finally, this document is presented to the project steering committee, and the project is formally completed.
This basic project plan gives you an overview of the planning and progress of a relatively small project. You can see the impact of lab testing and pilots on the final design and deployment. It is also clear how several activities, such as client communication and support planning, are not on the critical path and can be undertaken contemporaneously with other activities.