Developed by:

<Customer Name (please do not include a logo) and Project/Deliverable Name>

Project Plan

Version <x.y>

January 2007

Contents

Contents 3

Tables 6

Figures 8

About This Project Plan 10

History 10

Review 10

Document References 10

Introduction 12

Executive Summary 12

Purpose 12

Scope 12

Project Definition 14

Project Objectives 14

Method of Approach 14

Project Deliverables 14

Project Scope 15

Constraints 15

Exclusions 15

Interfaces and Dependencies 15

Assumptions 16

Project Organizational Structure 18

Project Management Team 18

Project Management Team Contact Details 19

Project Escalation Procedure 19

Project Quality Plan 20

Quality Responsibilities 20

Standards 20

Key Deliverable Quality Criteria 20

Quality Control 21

Requirements for Project Management 21

Requirements for Project Deliverables 21

Quality Log 21

Change Management 21

Requests for Change 21

Project Issues 21

Configuration Management 22

Identification 22

Control 22

Status Accounting 22

Verification 22

Project Controls 23

Project Review Meetings 23

Customer Project Status Reports 23

Jeopardy Report 23

Project Closure 23

Initial Risk Log 25

Contingency Plans 27

Project Filing Structure 29

Project Plan Acceptance 31

Role Descriptions 33

Initial Project Schedule 35

WBS and Responsibility Matrix 37

Initial Quality Log 39

Initial Issue Log 41

Initial Risk Log 43

Glossary 45

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Tables

Table 1 Revision History 10

Table 2 Revision Review 10

Table 3 Document References 10

Table 4 Role Descriptions – Terms of Reference 33

Table 5 Initial Project Schedule 35

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Figures

Figure 1 Project Management Team 18

Figure 2 Project Manager Team 19

Figure 3 WBS, Related Activities and Responsibility Matrix 37

Figure 4 Initial Quality Log 39

Figure 5 Initial Issue Log 41

Figure 6 Initial Risk Log 43

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

About This Project Plan

Author: <Author Name>

<Organization>

Change Authority: <Change Authority>

Reference Number: < Document reference number>

History

Table 1 Revision History

Version No.	Issue Date	Status	Reason for Change
<1.0>	<dd-mmm-yyyy>	<Draft, Released>	<First release, update, etc.>

Review

Table 2 Revision Review

Reviewer’s Details	Version No.	Date
<Name> <Organization>	<Version number>	<dd-mmm-yyyy>

Document References

Table 3 Document References

No.	Description	Ver. No.	Date	Author
<No.>	<Document Title/URL and Description>	<Ver>	<dd-mm-yyyy>	<Name, Customer/Cisco>

Change Forecast: <High/Medium/Low>

This document will be kept under revision control.

A printed copy of this document is considered uncontrolled.

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Introduction

Executive Summary

<Give an executive summary of the report to allow readers to quickly get a view what the project was about and what the result was.>

[example]

The <customer> project started on January 2^nd 2001 and ended on May 11^th 2001. In addition, there was a 30-day acceptance period after that but during this time no active project tasks were carried out.

The projects main objectives were to do the design for the complete new campus network at <site> to stage a smaller pilot network and to deliver support during the integration test phase. All the project objectives were fulfilled. The project ended successfully on time and on budget on May 11^th.

Purpose

<The purpose of this document is to compile the outputs of the project planning meetings for the <Customer, Project Name> and to create a consistent and coherent document that is used to guide both the execution and control of the project. This document further enhances the detail of the projects deliverables, time scales, organizational responsibilities and controlling mechanisms as agreed with the Statement of Work. This document is subject to review and changes and will be updated accordingly, with all reviewers to approve.>

Scope

<The scope of this document is to detail the requirements needed, to deliver the <Customer, Project Name> by utilizing the Project Management Methodology through the executing and controlling processes.>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Project Definition

Project Objectives

<Specifically what is required to be achieved by the project, expressed wherever possible, in measurable terms; it is often helpful to identify separate objectives for the project itself (e.g. target dates, expenditure profiles) and the project outcome (what the end-product is required to deliver during its life). If applicable, Insert a high level network design.>

Method of Approach

<Define the method to be used to deliver the project, break the project into various controllable phases that form a basis for approval. Indicate all major and interim milestones. The major deliverables identified in the section below need to be approved before moving forward to the next project stage.>

[example]

This project is to be managed utilizing the Systems Project Management Methodology, which is based upon Project Management Institutes Body of Knowledge (PMBoK).

The agreed method of approach for this project is to section the work into <Number> phases.

Project Deliverables

<Indicate the main end products of the project. These are based on the initial customer requirements.>

[example]

· Documents

· Network Solution

· Network Management

· Acceptance Timeframe

· Meeting minutes

Documented tasks should be located in the WBS and Responsibility Matrix section of this document. The high level baseline Project Schedule to be located in the Initial Project Schedule section of this document.

Project Scope

<The major areas, functions, processes etc to be addressed during the project - essentially what is “included” and what is “not included”. A simple "scoping diagram" may be appropriate.>

Constraints

<Restrictions on time, resources, funding, and/or the eventual outcome - a statement of the "no-go" areas for the project. Reference to the PMI Triple Constraint, time, cost and specification.>

Exclusions

<Are there any exclusions to scope, deliverables or products which need to be identified at this stage so that implications of such exclusions can be assessed. Products could be referred too as Other Equipment Manufacturer's (OEM) products that are not part of this project.>

Interfaces and Dependencies

<Identify the current known interfaces of the project. These may be interfaces between this project and other projects or technical interfaces between systems/functions.>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Assumptions

<Similar to constraints but more “expectation” than “restriction”. An initial list of assumptions can be copied from the Statement of Work as a starting point to a more detailed list.>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Project Organizational Structure

Project Management Team

[This explains who will be on the project management team. Roles and Responsibilities should already have been agreed and signed up to in the SOW; they may not need to be included in the Project Plan. Role Descriptions should be documented in the Role Descriptions section of this document. Details of actual responsibilities to Work Breakdown Structure level would be located in the WBS and Responsibility Matrix section of this document]

Figure 1 Project Management Team

Project Management Team Contact Details

<Enter the contract details from the Project Control Register spreadsheet.

To cut and paste this table successfully: Open Excel, highlight the area to be copied and select EDIT, COPY. Open the Project Plan document and place the cursor where the table needs to appear. Select EDIT, PASTE SPECIAL, Formatted Text (RTF). The table will now appear in the document. Click once on the table, then select TABLE, TABLE AUTOFIT,AUTOFIT TO WINDOW.>

Figure 2 Project Manager Team

ID	Company	Location	Division	Title	First Name	Last Name	Initials	Role	DDI Nr	Mobile	Email	Comment	Office Main Nr	Fax	Address(i)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Project Escalation Procedure

<Document the necessary steps required to escalate project issues to higher authorities within the customer and Cisco's organization. Include all customer and Cisco escalation personnel contact details. Define the criteria used to trigger the escalation process, and the format of the information that will be given to the management in the escalation path.>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Project Quality Plan

<Derived from the “Customer’s Quality Expectations”, its purpose is to define how Cisco intends to deliver the project which meets the Customer’s Quality Expectations and Cisco's Quality Standards.>

[example]

The quality plan is built on a strategy of identifying risks, mitigating them wherever possible and producing deliverables to an agreed quality standard.

Quality products are:

· Issue Log

· Risk Log

· Quality Log

· Project Quality Plan

· Agreed deliverables - Working services, Network Management solution etc.

Management deliverables being dynamic in nature will be assessed for quality through continual assessment through project review meetings.

Quality Responsibilities

<Indicate owners from both Cisco (PM, PE , Partner etc.) and Customer for quality responsibilities of defined deliverables.>

Standards

<Indicate any standards both Cisco and Customer that are to be followed e.g. ISO9000, Cisco Project Management Methodology etc.>

Key Deliverable Quality Criteria

<A summary of Technical/Specialist Standards and Quality Management Standards that must be adhered to and reflected in the creation of the deliverables. This will include both <Customer> and Cisco Standards where appropriate. Industry Standards, Professional Standards and ethical approaches must also be included. If there is no quality standard then something along the lines of ‘to Cisco standard deliverables including NRFU, SRS, SSF, NIP ……’.>

Quality Control

Requirements for Project Management

<Add the agreed quality control requirements for the management of the project. Project Schedule, Reporting.>

Requirements for Project Deliverables

<Add the agreed quality control requirements for the management of the project s deliverables. Frequency of quality checks, quality reviews of in progress deliverables.>

Quality Log

<Document the use of the quality log and its agreed layout with the customer.>

Please refer to the Quality Log section of this document.

Change Management

<A brief summary of how changes will be managed and authorized. Information on this should be available within the Statement of Work. This can be relate this to the Cisco's and the customers Quality Management System and Quality Procedures.>

Requests for Change

<Any proposed modification to the agreed specification, schedule or acceptance criteria of any deliverable will be in the form of a change of Statement of Work. This includes any 'out of scope' requests from the customer or project additions, which may have been accepted by the customer, from the Cisco project team through added functionality.>

Project Issues

<All project and technical issues associated with the project inclusive of interfaces affecting the project.>

All issues will be recorded onto the Issue Log, which will indicate the following:

· Unique ID number

· Date Raised

· Type of Issue

· Description

· Owner

· Status

· Updated

· Date Closed

All issues raised by either 'Customer' or Cisco will be logged, assigned an owner and actioned accordingly. The Issue Log will be reviewed at project progress meetings as agreed.

Configuration Management

<The arrangements for control over the project’s assets (the deliverables of the project); this will cover the identification, control, status accounting and verification of the Products.>

To manage the projects products to allow the following:

Identification

<Identifying and describing the deliverables required by the project.>

Control

<The ability to freeze the deliverables and make changes only through the change control process and obtaining agreement for the change from the agreed controlling authority.>

Status Accounting

<The recording and reporting of the information about a project deliverable and the ability to track the deliverable through all changes in status.>

Verification

<To review and audit the deliverable, to ensure conformity of its actual state against its status recorded in the Configuration Management records.>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage return following this line>

Project Controls

Project Review Meetings

<The project review meetings will be undertaken <Time Period> between the Project Manager and project team to report on progress of work being undertaken, any problems being experienced, scope changes, cost changes and future expected target dates of the completion of work. The meetings will take the form of a face to face meeting or through a conference bridge, whichever is deemed appropriate. Detail of steering committee meetings should also be included here.>

Customer Project Status Reports

<The Project Manager will provide the Project Status Report to the <Customer> and Cisco project teams on progress against the project schedule, outlining in addition current or potential problems and expected events in the near future. These reports will be based on the reviews received from the track Team Leaders. The frequency of these reports will be <Time Period>. It is suggested that the customer is shown a copy of the PSR to familiarize them with the format.>

Jeopardy Report

<If the tolerances agreed for the project schedule, project costs or specification are forecast to be exceeded, delayed or altered the Project Manager will raise a Jeopardy Report to the <Customer> Project Executive. It is suggested that the customer is shown a copy of the Jeopardy report to familiarize them with the format.

The reason for the Jeopardy Report may be due to the following:

· Major change to requirements

· Failure of the project to meet planned costs or schedule

· Resource Implications>

Project Closure

<This is project control point to undertake the following activities:

· Confirmation of delivery and acceptance of all expected project deliverables as agreed within the Statement of Work

· Confirmation that any issues raised have been resolved or forwarded to the appropriate body

· Any lessons learned have been documented

· Approves any plan for Post Implementation Review

· Approves the end of the project

· Authorizes formal project closure

· Produce project completion report>

<SECTION BREAK
to avoid header/footer and page setup problems do not remove the carriage